Hi, thanks for your time and answer. I am sure my storage vendor will disagree with you :-) The FS corruption are sometimes shared storage and sometimes not. either way the FS are not mounted on the other systems and there should be no reason for corruption. let's put the corruption aside. all the thing you say are normal to linux shouldn't be normal and should not be accepted. an open file should not be deleted in any case. i am using online resize (normally it works) but sometimes it asks me to umount the FS and fsck it. the hole approach just seems immature... I am having a hard time accepting any of the stuff you call "normal" in an enterprise production solution.
Offer On Thu, Dec 15, 2011 at 9:07 PM, Richard Troth <vmcow...@gmail.com> wrote: > Your #2 and #7 and #8 are all normal. The rest has me worried. > > Something bad is happening with the underlying storage. > > My replies peppered throughout: > > > This is not a z/Linux or z/VM question but Let me ask you guys something > > about ext3... I guess that most of you are using it in production... > > I use EXT3 personally, and we use it at work, and I see it "all around". > > > How is it possible that i am using ext3 in my production systems and > > face stuff like: > > 1. Corrupted FS during normal work that needs to be fixed with fsck or > > worse restore from a backup > > It's good that this is your #1 question, because it is probably the #1 > clue. > > In my experience, it is quite rare for EXT3 to be corrupted. > > Define "restore from a backup". Tell me you don't mean image backup. > A true image backup of an EXT3 should restore more cleanly than an > (active) EXT2, but ... where was the image copy taken? If not from > the owning Linux system, then all bets are off in case blocks were not > flushed from cache and written to disk. > > If you're on VM and try to CP LINK the disk to make a copy, then the > copy will almost certainly NOT be current. This is not a problem with > VM nor with Linux on VM nor with zLinux. It is the nature of shared > disks. When they are being written, what the sharing system sees will > never match what the writing system sees. > > > 2. Resizing a FS requires me to fsck before I resize > > That is normal for offline resize. > > > (as if the FS does not > > trust itself to be valid forcing me to umount the FS before a resize) > > You cannot resize a mounted filesystem unless you use the online > resize tools. I don't use them. (Mostly because they are still "new" > to me.) But online resize is really convenient, and is reliable > (especially when driven via distributor tools). > > If you try to resize a mounted filesystem with the offline resize > tools, you will trash it. > > > 3. Resizing a FS offline actually corrupts the FS > > This goes back to your #1. > It makes me wonder what else is able to touch the underlying storage. > Is the disk shared? Is it possible that there is a disk overlap? > This symptom does not point to EXT3 per se, but to the media. > > > 4. The fstab parameters, that states that it is normal to fsck your FS > > every boot or every several mounts... > > EXT3 is a journaling filesystem, so you could get away without a > forced 'fsck' as often. > > How often is this filesystem unmounted and remounted? How often is > the owning system rebooted? Maybe you need to adjust the "number of > mounts". That setting is in the superblock. Use 'tune2fs' most > likely. > > > 5. FS is busy although it is not mounted or in use by anyone... > > Here's another clue. It comes back to #1 again. > > A corrupted filesystem can appear to be "stuck busy". > > > 6. fuser command will not always show the using processes > > FS corruption ... again. > > > 7. open files can be removed without any warning from the rm command. > > NOT an error. That is normal Unix behavior. > > But it is a clue. Maybe something unique to your environment is > making an incorrect assumption about this filesystem? > > > 8. removing files from the FS will not free up space in the FS > > This goes along with #7. Files can be removed from the directory (and > rendered invisible) but still be in use. Blocks are still used, until > the last process with an open filehandle to that file closes it. THEN > the file is truly removed and all blocks are freed. This is normal. > > > I can go on with Linux stuff that bother me but lets stick to ext3, and i > > guess maybe some of my issues might not be accurate. > > Aside from 2, 7, and 8, the rest of your points suggest that something > is wrong. > If this is your only exposure to Linux, I can see why you would be > very disappointed. > Here on the Linux-390 discussion list, there are plenty of people who > will agree: not normal, and not acceptable. > > > I am a z/OS system programmer and maybe i am expecting for too much, but > > even windows don't have this kind of stuff anymore... > > See my prior paragraph. I would agree with your conclusion, but have > never had such trouble from Linux. (Until Windows 7, Linux for me was > years ahead of Windows in terms of reliability and stability ... and > the jury is still out w/r/t W7 because I have not had time to use it > much.) > > Some of the behavior you see should be reflected in Unix on MVS (USS). > > > I am using redhat V5.2 (not too old) and recently was asked from my local > > redhat representative to upgrade my kernel to V5.6 (2.6.18-238). > > To my huge surprise i am still seeing this kind of issues even with the > new > > kernel... > > I see no reason, based on your report, to think that you have a kernel > problem. > > > Am i alone here? how can this be? Why are we all using linux if it is > still > > not ready for production? > > Yes, and no. You are not alone in astonishment with using Linux. You > are somewhat alone in the number of problems and the severity. > Hundreds of us have been using Linux on the mainframe for a long time, > some of us for more than a decade. And most of us have used Linux on > other platforms for 10 or 15 years ... or more. > > > will ext4 fix that or is it just bigger, faster but based on the same > > unstable technology? > > EXT4 will not help in this case. > You have a storage problem, not a filesystem problem. > > > Blowing out some steam... > > Offer Baruch > > -- R; <>< > Rick Troth > Velocity Software > http://www.velocitysoftware.com/ > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu 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/ > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/
