Given the move from Reiser to Ext3 as the default. I personally am not pleased but at the same time the Reiser project seems to have frozen over.
I’ve been using Reiser since SuSE 7.2 and i’ve only have two instances where I lost data but recovered a total of 500+ GB but I can’t say the same for my Ext experiences.
So I’m looking to XFS and BtrFS for future needs?
Comments? Suggestions?
On Fri, 2009-03-27 at 05:56 +0000, dadeisvenm wrote:
> Given the move from Reiser to Ext3 as the default. I personally am not
> pleased but at the same time the Reiser project seems to have frozen
> over.
>
> I’ve been using Reiser since SuSE 7.2 and i’ve only have two instances
> where I lost data but recovered a total of 500+ GB but I can’t say the
> same for my Ext experiences.
>
> So I’m looking to XFS and BtrFS for future needs?
Strangely, Reiser4 work does continue… and I believe that
some of the developers there believe they’ve got something
even better than btrfs.
I’m leaning toward btrfs… but certainly XFS is also
a valid contender with some maturity that btrfs won’t have
(for awhile… duh).
Oh… and lastly, just because reiserfs (v3) doesn’t have
much happening doesn’t mean it’s dead.
On the other hand I have had messages from reiserfs-3 which no amount of searching could find good explanations for. Fortunately they are cleared by reiserfsck and no data has been lost yet, but it’s a worry.
Currently I’m using ext3 and XFS. I think ext4 will be the successor to ext3 in the medium term and beyond who knows, maybe btrfs or a GPLed ZFS?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I use XFS for everything (except my boot partition now with version 11)
and haven’t had any issues. Before that I used ReiserFS 3 for everything
and never had issues either.
Good luck.
dadeisvenm wrote:
> Given the move from Reiser to Ext3 as the default. I personally am not
> pleased but at the same time the Reiser project seems to have frozen
> over.
>
> I’ve been using Reiser since SuSE 7.2 and i’ve only have two instances
> where I lost data but recovered a total of 500+ GB but I can’t say the
> same for my Ext experiences.
>
> So I’m looking to XFS and BtrFS for future needs?
>
> Comments? Suggestions?
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBAgAGBQJJzNc+AAoJEF+XTK08PnB5qe8P/1ggLsLkLsS5ts6zmhoC6eyh
ZKgH6nsu22G8ljnFwavmWCV8CzO9H6lz8aSZJNvDcJqjUyyknCnOyYsCPFM5k62o
VaCM11hjCxq6V9UOfkN1yowmpQJQi4gJU9YEWlqtCBOFSukBbu+CltZg5c8tjmyf
amnEtc8Gbu9r2HnZCMVhfAaxcLG3VfzI7gulk0yUC6FImSpSmRET0htYmY6pBdgK
peKfmizZqq2eTDNNVmKiPvvtuCJpWPu+nXvQMYUO51SZmbIBV04NY4O/aFaq5lhB
IYTxfmQ6r7DwAGteOf1Ws7vqvnvbFFEdnVkJRrIVhuEv0fYhAQwMBR1hL44mq9tq
ATBqpYvwve3LlL6hQDTz2IYoxetEQ0W/C9Yb3GoaW9e3IjruioO5RTG62+7V2B4U
tEWfB6Vnwws4WTX3kyVSj9McSZr15ZgYNa+vy546TwQKNXuL7EHN94SNUzmn+ygX
Wa8BW6uavitgLIlFNIJjeA83jJ8V5g+1YGOXN4Geqn4E0zU8pg4x/c+TT9eoMl63
sYI55PBOfi+vb2CZDWUCndu+UBLhJ98cONXZB7kUhT0Ws125u30KOpS4WH32lcrx
kIbw9jErJ256xiW9ocL8conP6N8UcvGHzRcjAFcNUPN24u6oEyepN7Zylw/lLFrP
4dfyt1ZoP/ZLF+jYzyeB
=qL4E
-----END PGP SIGNATURE-----
Correct me if I am wrong, but doesn’t XFS have some of the same issues that Ext4 has with the way they handle fsync and journals?
I am not sure if this has been fixed, so please understand that my concerns are possibly already addressed, but my understanding was that XFS and EXT4 had issues where the metadata was consistent, but the data was not written before the commit was issued claiming the data was consistent. Thus, if a power failure or other problem with the server occurs, the metadata pointing to the data would show a sync’d write, but the data was never flushed from buffer to the disk.
Even as SUSE wants to stear away from it, I think they should pour some serious development into keeping JFS alive or getting btrfs running faster.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I don’t know… I’ve used it for quite a while primarily and never had an
issue but I’m not good enough to figure out filesystem code.
Good luck.
mark54g wrote:
> Correct me if I am wrong, but doesn’t XFS have some of the same issues
> that Ext4 has with the way they handle fsync and journals?
>
> I am not sure if this has been fixed, so please understand that my
> concerns are possibly already addressed, but my understanding was that
> XFS and EXT4 had issues where the metadata was consistent, but the data
> was not written before the commit was issued claiming the data was
> consistent. Thus, if a power failure or other problem with the server
> occurs, the metadata pointing to the data would show a sync’d write, but
> the data was never flushed from buffer to the disk.
>
> Even as SUSE wants to stear away from it, I think they should pour some
> serious development into keeping JFS alive or getting btrfs running
> faster.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBAgAGBQJJzTd/AAoJEF+XTK08PnB5ON8QAII3EYryqVuTf7cLCRoHmpHg
WuCPNCJ5KVjRMaytcDd3WyLElFw2a7qf4RSKW0A4By0NLdQikcufE63OI8ykzCZ1
bntkHllizQ8TqIlHjmbcXrV79fGHMyOO5qIW1vVqhG/rvQQwmYtatcl9I3bpo5Z+
KwRxk6eT8A12d3WfawIHaYLHxOY+1YdRO++B/K5pO/7PZTM2QUhuN146t4TOUqyv
s/kWZsP+iU0gD+Tv5pmpK2k3krFgcBFsE/VaiOCYki9RbnOKTCmtVHf+Ewg3qgu4
+ebBOpZaHsIOljimQNWq7hy+L1j8OJH4tP6PGEjG8zzoDmL7i2LY4X5HVbOgj8V/
zy9wBNSYEafNHnbYiSB9YJ4AYfME1EUANZ0OtB92mE19gT6fUI51qnWQ4BOosFaT
bDSQqFmbD4vPwi0HKN4TAhGy9Rt0LNTXATRUEXCNiLA27ybL/FsnmevRwXEiwL3V
HLyKdkRZmlMvwNSv4y1kGvR7D+9TonLd0Ix23KqYpSgl3SUEQyrPvT8qfBL3Ke82
DU4516cu9yB4fjYcPoH6xDwgesUx1s+omkJlOC+/BpgHIzEv2dojXwX3sW0M51V5
PY63bhltG/aIAQzg74UlKl36+WJy3oNNd80P9Ehptcv+UTfwfkfF8kqx4UW+lutS
GBy2idMW3MKc6mCxLxgO
=Bu+W
-----END PGP SIGNATURE-----
As a former user of Reiser3.6, I have switched to XFS - I am very satisfied with it’s speed and stability. In addition, it will be supported by Linus in the future versions of the Linux kernel.
However, the future of Reiser looks a little bleak.
For more info about XFS you can check out the following link:
Cheers!
You’re probably thinking of this issue:
Ext4 data loss; explanations and workarounds - News - The H Open Source: News and Features
The problem is really with the application. If it really must make sure that the data is on disk in case of a crash, it should call fsync. It just so happened that ext3 masked the error.
See that article for the new option for ext4 that avoids the problem for non-compliant applications.
You may agree with the author of the FS, Theo Tso. I do not. The issue I am discussing, is that while the spec says that the metadata needs to be written, but the user cares about the actual data not the metadata.
This is a debate that has been already waged. Sacrificing consistency for performance will give you neither, in the worst case.
Ext4 can operate in FULL journal mode where both meta-data AND data are ensured. Further, Ext4 by default has journal checksumming and supports ordered writes if you want to average speed vs data integrity. None of these features are present in XFS or JFS and personally I’ve lost much more data under XFS than under Ext3 or ReiserFS, in fact, none so far under Ext3 and I’ve done pretty nasty things
There have been many occasions that the moment was there to change the old Reiser partitions to ext3, and it never happened. Simply because I’ve never had any data loss on them, they never gave up on me. With XFS I’ve had some realy weird issues.