Jeffrey W. Baker wrote: > The latter part of this sentence is not supported by the former,You are correct, rather googling reveals that the locking model in the kernel doesn't support it, and there may be raced conditions triggered only by having a block device mounted and doing raw I/O on it at the same time.
The kernel developers are certainly not interested in supporting such behavior, so it still isn't safe.
What kernel? What distro? Unbuntu has some patch that causes XFS corrpution under seemingly random circumstances (I'm working on tracking it down).No, actually, it isn't. Look at the XFS mailing list. There's a number of reports of boinked volumes just in the last month.
2.6 has had a number of XFS-related bugs that could cause data corruption under a number of situations.
Because the NFS code isn't locking properly? Because the XFS code isn't locking properly?This does not explain why XFS is frequently reported to become corrupted when exported over NFS.
Just because XFS over NFS causes corruption doesn't mean that XFS LVM and MD shouldn't be trusted. NFS is above XFS, LVM and MD are below it.
It doesn't really follow to not trust XFS on MD and LVM due to corruption using NFS.
I have *zero* trust in Linux's NFS implementation anyway (even though it's purportedly become better) since it bit me so bad back in teh 2.2 days.
What kernel? What situation. Unfortunately, especially as of late, there have been several known "gotcha" situations that will cause data corruption, especially under 2.6 (4K stacks being one, very full fileystems another).I came across this conclusion by losing numerous large filesystems in the course of only 6 month before abandoning XFS.
Adam