attack upon XFS, misinformation abounds, linux-raid list
In a recent linux-raid list thread here:
http://marc.info/?l=linux-raid&m=137072140106867&w=2
seriously flawed arguments against the reliability of XFS, and even the performance of XFS, are made. The OP even quotes Dave's LCA presentation as a performance reason to avoid XFS. The party really gets started at paragraph 7.
I made a brief effort to debunk his claims and explained that he can't have O_PONIES, that he should use fsync or O_DIRECT, etc for data safety. To non experts/advanced filesystem users, his long winded argument may be persuasive. Obviously none of you experts has time to debunk every such post, but this one may be worth a read at least, especially given the weight Google gives to vger lists.
Signature · 7 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines · Stan Hoeppner
In a recent linux-raid list thread here:
http://marc.info/?l=linux-raid&m=137072140106867&w=2seriously flawed arguments against the reliability of XFS, and even the performance of XFS, are made. The OP even quotes Dave's LCA presentation as a performance reason to avoid XFS. The party really gets started at paragraph 7.
Quoted 6 lines
I made a brief effort to debunk his claims and explained that he can't have
O_PONIES, that he should use fsync orO_DIRECT, etc for data safety. To non experts/advanced filesystem users, his long winded argument may be persuasive. Obviously none of you experts has time to debunk every such post, but this one may be worth a read at least, especially given the weight Google gives to vger lists.
Thanks for pointing that out - I responded as well.
Funny that he decided to use ext4 after basing it on a google search for "xfs zero" and did not bother to the same query with "ext4 zero length files" :)
Ric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines · Stan Hoeppner
In a recent linux-raid list thread here:
http://marc.info/?l=linux-raid&m=137072140106867&w=2seriously flawed arguments against the reliability of XFS, and even the performance of XFS, are made. The OP even quotes Dave's LCA presentation as a performance reason to avoid XFS. The party really gets started at paragraph 7.
Quoted 6 lines
I made a brief effort to debunk his claims and explained that he can't have
O_PONIES, that he should use fsync orO_DIRECT, etc for data safety. To non experts/advanced filesystem users, his long winded argument may be persuasive. Obviously none of you experts has time to debunk every such post, but this one may be worth a read at least, especially given the weight Google gives to vger lists.
The really unfortunate thing about this is that the bug[1] which would prevent transaction flushing from happening got imported and shipped for a rather long time in RHEL. It's one thing to get a file zeroed that's a few seconds old, but having the same happen to files which haven't been touched in hours, even before issuing manual sync, is certainly not very reassuring.
As a very satisfied user of XFS on CentOS 6, I have been nervous enough about that to go through the trouble of rebooting our main server for a kernel upgrade a few weeks ago. Thanks to RedHat's deceptive tactics regarding kernel patches, I have also not been able to pin-point the exact range of kernel versions affected by this in a reasonable amount of time and hence have not found out (thankfully not the hard way) if it was even necessary.
[1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/kernel.html
"BZ#855139"
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 16 lines · Stefan Ring
Quoted 8 lines · Stan Hoeppner
In a recent linux-raid list thread here:
http://marc.info/?l=linux-raid&m=137072140106867&w=2seriously flawed arguments against the reliability of XFS, and even the performance of XFS, are made. The OP even quotes Dave's LCA presentation as a performance reason to avoid XFS. The party really gets started at paragraph 7.
Quoted 6 lines
I made a brief effort to debunk his claims and explained that he can't have
O_PONIES, that he should use fsync orO_DIRECT, etc for data safety. To non experts/advanced filesystem users, his long winded argument may be persuasive. Obviously none of you experts has time to debunk every such post, but this one may be worth a read at least, especially given the weight Google gives to vger lists.
Quoted 6 lines
The really unfortunate thing about this is that the bug[1] which would prevent transaction flushing from happening got imported and shipped for a rather long time in RHEL. It's one thing to get a file zeroed that's a few seconds old, but having the same happen to files which haven't been touched in hours, even before issuing manual sync, is certainly not very reassuring.
Bugs and regressions are always unfortunate, and this one was no exception. It was pretty obscure, but we (mostly Dave) worked with our customers to identify & resolve it within days of the bug report.
As far as I know, the bug existed only for a crash, not a reboot.
Quoted 4 lines
As a very satisfied user of XFS on CentOS 6, I have been nervous enough about that to go through the trouble of rebooting our main server for a kernel upgrade a few weeks ago. Thanks to RedHat's deceptive tactics regarding kernel patches, I have also not been able
deceptive - adj. - Giving an appearance or impression different from the true one; misleading.
which sounds pretty damning. Perhaps more accurate is:
obfuscated - adj. - Rendered obscure, unclear, or unintelligible ;)
Quoted 3 lines
to pin-point the exact range of kernel versions affected by this in a reasonable amount of time and hence have not found out (thankfully not the hard way) if it was even necessary.
It was introduced in 6.2 and resolved in 6.4, as well as 6.2 and 6.3 z-stream kernels. Those are the sorts of things Red Hat support can help customers identify more quickly & clearly.
-Eric
Quoted 8 lines
[1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.4_Technical_Notes/kernel.html
"BZ#855139"_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Hey Stan,
Quoted 8 lines · Stan Hoeppner
In a recent linux-raid list thread here:
http://marc.info/?l=linux-raid&m=137072140106867&w=2seriously flawed arguments against the reliability of XFS, and even the performance of XFS, are made. The OP even quotes Dave's LCA presentation as a performance reason to avoid XFS. The party really gets started at paragraph 7.
Quoted 6 lines
I made a brief effort to debunk his claims and explained that he can't have
O_PONIES, that he should use fsync orO_DIRECT, etc for data safety. To non experts/advanced filesystem users, his long winded argument may be persuasive. Obviously none of you experts has time to debunk every such post, but this one may be worth a read at least, especially given the weight Google gives to vger lists.
I gave it a quick read, but since I'm not on linux-raid I don't have a good way to reply to Steve. Could you bounce that message over? I'd be happy to try to address a point or two...
Thanks,
Ben
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 1 line · Stan Hoeppner <stan <at> hardwarefreak.com> writes:
but this one may be worth a read at least
How flattering that you felt you needed to seek out reinforcements. :-)
-Steve
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Steve Bergman
Quoted 1 line · Stan Hoeppner <stan <at> hardwarefreak.com> writes:
but this one may be worth a read at least
How flattering that you felt you needed to seek out reinforcements. :-)
More like, "Hay guys, some dude is talking smack about Mom." ;)
Seriously though, expanding the participant list to the devs has been a positive thing overall, has it not? Worth noting, I've been a subscriber to the XFS list for a few years--no seeking was required.
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs