On 20/06/11 05:15, Linda Walsh wrote:
Sid Boyce wrote:
The last kernel problems I had going back a few months was with XFS where modules were being zeroed out on boot sometimes, so I moved to ext4.
ext4 is has options like 'write-through', that disallow buffering of large writes. If you have unreliable hardware, subject to crashes, it is probably a better choice.
After I went back to ext4 I saw a kernel patch for XFS. The symptoms weren't exactly the same but there had a fair similarity. The problem was with root on XFS on 2 systems. The same HD's are in the systems, mounted and used but not as root.
xfs was designed for servers that have UPS's -- if used with RAID, then with battery back-up on the RAID card as well, it wasn't designed for systems that could crash at any point....
You have to match the file system with your system's usage/reliability. My systems are all on UPS's, I think I had one XFS file corruption in the 10+ years I've been using it...but my systems are also usually on 24/7. On my largest array (a home server), I get max-read/write (large files) of 1GB/s read & write. What do you get with ext4?
All mine, except for 2 laptops are on UPS's. It was just on a series of vanilla kernels when the problems happened. I would build a kernel, check that the modules were OK "sync;sync;sync" and sometimes reboot next day or days later only to find most of them zero bytes. I could eventually get the modules to work by booting and doing "make modules_install" and rebooting.
The file zeroing, BTW, was required for SGI's "Trusted Irix", as any object in the system must be zeroed out before being given to a user. Since XFS allows you to allocate space and THEN write to it -- if you allocate the space and you think you've written to it, but the kernel hasn't flushed it's buffers yet...(between xfs's delayed writes and kernel's buffering can be over 15 seconds or more (it is tunable...BTW to more often or less ... on a laptop setting it to 60 seconds can let the hard disk stay off for most of the time)....
BUT....file 'meta' info (names creation, size) gets written immediately to the log...it's file 'data' that can be slower to flush (again, a tunable in /proc), but if you crash or lose power before your buffers are flushed, then the allocated space is ensured to be zeroed when the fs is mounted -- otherwise, you run into a security risk of being able to read someone else's data.
It USED to be allowed to disable 'unwritten extent support' at mkfs time, but apparently it was considered too insecure.
No crashes, no power loss - the UPS's see to that. I knew that so that's why I used sync after modules_install. The problem only came on with a 2.6.3x series of kernels, -rc and -rc-git. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org