On Dec 15, 2011, at 10:09 AM, Offer Baruch wrote: > 1. Corrupted FS during normal work that needs to be fixed with fsck or > worse restore from a backup
If you use the E2FS utility to edit linux files on CMS, using an ext3 filesystem that has not been cleanly unmounted, you will see this after bringing the filesystem online in linux, due to an unfortunate interaction with the filesystem journal. We ran into this where we had CMS automation changing linux IP address information, in an old DR process (that was changed later, partly for this reason). > 2. Resizing a FS requires me to fsck before I resize (as if the FS does not > trust itself to be valid forcing me to umount the FS before a resize) > 3. Resizing a FS offline actually corrupts the FS > 4. The fstab parameters, that states that it is normal to fsck your FS > every boot or every several mounts... These three reasons (in reverse order of priority, for us) were why we switched from ext3 to xfs for our linux deployments. The periodic fsck at boot caused a "thundering herd" problem after a POR (or during a DR test) which made these things take many times longer than was strictly necessary. The balkiness surrounding online volume resizing was also an important motivator... I personally was completely disgusted that it would _sometimes_ work for ext3, and there was no real way to tell ahead of time whether it would or wouldn't. As we were going ahead full-steam with LVM we really didn't have the time or inclination to argue with it. xfs solved both these problems for us, and apparently gave us better filesystem performance for lower CPU cost too---though I never quantified it beyond just the sense and collected anecdotal reports from our customers. I never had cause to regret abandoning ext3, though SuSE accidentally leaving it out of the YaST installer in SLES 11 was annoying. > 7. open files can be removed without any warning from the rm command. > 8. removing files from the FS will not free up space in the FS This is just the way UNIX works. Linux could not reasonably change this, though others have already written more detailed replies on the topic. ok bear. -- until further notice ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
