On Sun, Jun 9, 2013 at 12:46 PM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote: > 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. 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 xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
