Re: Raw Disk still preferred for 11.5? - File system type for SDS

Thanks so much for all the feedback, I have learned a great deal. I think we will go with a cooked system. I think it will be better administratively, since they wont give me root access to the new servers and it will be a chance to try something new and test the performance. Now I am getting questions from the sys admins about file system type. We are going to implement SDS servers that will access the same disk on a SAN. As of today.. the plan is to use OCFS file system. (rather than Risser or ext3). Any comments on this? Also - I have been reading the manuals, and blogs, and whitepapers, etc., about seeting up SDS servers and it really doesnt talk much about how the shared disk is accesed/referenced on the SDS servers. I have always figured the sys admins should know how to do this... but it is causing a lot of questions. Is there somewhere I can send these guys to give them the info they need to set up the shared disk part of it? Thanks a bunch!!! Laurie Laurie Gustin IT Programmer Analyst Department of Public Safety lgustin@utah.gov 801-965-4410 >>> Fernando Nunes <domusonline@gmail.com> 10/07/08 5:24 PM >>> InDeep wrote: > Fernando, > > Great article you put out. Yet another great Informix feature, > DIRECT_IO. I would not have read about this other than your article. > Thanks, but DIRECT_IO is just IDS way of taking advantage of a concept that exists... > I'd still steer clear of raw disks unless they were somehow proven to > add value, otherwise, I find them somewhat extra work. I guess I'm > admitting I'm lazy, and DBA work is not the only thing I want to do. > I'd rather work with cooked simply because it accommodates my laziness. > *<8o) What you call "laziness" is in my view a perfectly good reason to not use RAW. For RAW allocation you need root access... For cooked files you don't. Also, RAW cause a lot of human errors... > > If you are on raw disks, remember, unless you are on a SAN that can > provide san-level replication and san-level recovery of lost data, you > will be limited to Informix utilities to restore data. This is > something I'm not sure I'd want to limit myself to unless raw is > something that is a proven value-add, and something you just can't live > without. I still think cooked is fine for 99% of the situations out > there on Linux--but hey I could be wrong. > As I wrote, on Linux, I would not use RAW. On other systems it's very arguable what is best. Your reason (depending on IDS utilities) doesn't convince me a bit... They're the only choice to guarantee availability and consistency... -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list

OCFS is really only for Oracle. No need for that. *<8o) Laurie Gustin wrote: > Thanks so much for all the feedback, I have learned a great deal. I > think we will go with a cooked system. I think it will be better > administratively, since they wont give me root access to the new servers > and it will be a chance to try something new and test the performance. > > Now I am getting questions from the sys admins about file system type. > We are going to implement SDS servers that will access the same disk on > a SAN. As of today.. the plan is to use OCFS file system. (rather than > Risser or ext3). Any comments on this? > > Also - I have been reading the manuals, and blogs, and whitepapers, > etc., about seeting up SDS servers and it really doesnt talk much about > how the shared disk is accesed/referenced on the SDS servers. I have > always figured the sys admins should know how to do this... but it is > causing a lot of questions. Is there somewhere I can send these guys to > give them the info they need to set up the shared disk part of it? > > Thanks a bunch!!! > > Laurie > > > > Laurie Gustin > IT Programmer Analyst > Department of Public Safety > lgustin@utah.gov <mailto:lgustin@utah.gov> > 801-965-4410 > > >>> Fernando Nunes <domusonline@gmail.com> 10/07/08 5:24 PM >>> > InDeep wrote: > > Fernando, > > > > Great article you put out. Yet another great Informix feature, > > DIRECT_IO. I would not have read about this other than your article. > > > > Thanks, but DIRECT_IO is just IDS way of taking advantage of a concept that > exists... > > > I'd still steer clear of raw disks unless they were somehow proven to > > add value, otherwise, I find them somewhat extra work. I guess I'm > > admitting I'm lazy, and DBA work is not the only thing I want to do. > > I'd rather work with cooked simply because it accommodates my laziness. > > *<8o) > > What you call "laziness" is in my view a perfectly good reason to not > use RAW. > For RAW allocation you need root access... For cooked files you don't. > Also, RAW cause a lot of human errors... > > > > If you are on raw disks, remember, unless you are on a SAN that can > > provide san-level replication and san-level recovery of lost data, you > > will be limited to Informix utilities to restore data. This is > > something I'm not sure I'd want to limit myself to unless raw is > > something that is a proven value-add, and something you just can't live > > without. I still think cooked is fine for 99% of the situations out > > there on Linux--but hey I could be wrong. > > > > As I wrote, on Linux, I would not use RAW. On other systems it's very > arguable > what is best. Your reason (depending on IDS utilities) doesn't convince > me a > bit... They're the only choice to guarantee availability and consistency... > > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list

Hello Laurie, I don't know the SDS feature of Informix yet so please take my advice cautiously. On my cooked instances of informix the dbspaces do not have soft links. I don't need them because Informix is not tied to a / dev anymore. Second, if you use hardware mirroring always leave a little room in each mounted file system for the remappable I/O. So, for example, if the system administrators give you a bunch of 10.0 Gb mounts, only put 9.9 Gb dbspaces in each of them. That leaves 0.1 Gb for a bad spot on the disk to get re-written to from the good hardware mirror. And remember, you have to first touch the file and "chmod 660" it before you run your onspaces command to make it grow. It was weird for me at first to first "see" my dbspaces but you will soon learn some of the Informix internals just by running the "ls -l" command. And Nick is right. Sooner or later, you or a system administrator will accidentally remove a dbspace file. So test your backups and restores! -L.S.