(portions removed for brevity) > I am sure my storage vendor will disagree with you :-)
I did not mean to point at the vendor. It could be something in the configuration, in the layout, in the VM side ... any number of things. > 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. No. That is not the design of Unix or Linux. I can see that it is astonishing that an open file can be deleted, but that does not make it wrong. This feature turns out to be really very useful. When I found on HP-UX that it was not normally allowed, I was just as astonished then as you are now. (Except that I had the knowledge that HP had removed a useful feature from Unix.) Windows is not Unix, so they can make up their own rules w/r/t open files being deleted or not. > 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... As I said, I do not use the online resize (for reasons that I won't go into further). But it makes sense that if SOMETHING ELSE is wrong, and the online resize has detected a problem ... requiring you to unmount the filesystem is a basic safety requirement. > I am having a hard time accepting any of the stuff you call "normal" in an > enterprise production solution. Offer, I cannot make you "like" these things which are new to you. And I won't try. Clearly, something is trashing your filesystem(s). It is difficult to tell what, since we only just started the conversation. As a z/OS professional, you value high availability and you are accustomed to "live" changes. Linux runs on a broad range of hardware. "Unix", as a genre, runs on a broader range, and must accommodate sysadmins with varying skills. Most of the tools and utilities in Linux have been developed over time and tested by this broad range of people. So if the online resize detects a problem, it cannot assume that "the user" will be as highly skilled as you are. Most of us on this list are quite pleased to have Linux on the mainframe, and are anxious to help you, as a peer, to get your implementation working very very well. It will never work like z/OS (or even quite like USS). But we will try to walk you through making things reliable. (The filesystem corruption you describe is NOT normal and is NOT something any of us tolerate for production work.) Many of us on this list are also long time mainframe people. You are not alone. Given that so much code these days is written for the POSIX model, your best alternative (as a z/OS guy) to using mainframe Linux is to use USS. If you can get the porting done and can get support from your vendors, go for it! -- R; <>< ---------------------------------------------------------------------- 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/
