![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
fsck and its interaction with the "user" made sense with smaller machines with slower processors and I/O buses. "Users" usually had an intimate relationship with the data on the machine and wanted the hands on. More recently, I remember having a system fsck multi-GB filesystems after a crash. Not a good time having users call up and ask when things were coming back while fsck was running. You couldn't be sure when and if you were OK. At least with journalling you've got a fairly quick clue. I've used AdvFS on Tru64, the Veritas FS on Solaris, and ext3 on Linux. I don't have a lot of experience with ext3 except that it has worked OK when I've needed it. (I experienced a power outage this weekend so I have recent knowledge.) AdvFS usually worked but if it didn't you were SOL 97% of the time. Veritas FS has some tools to recover but you or your application may not like its idea of a recovered filesystem. Still I think journalled filesystems are de rigeur for any kind of time sensitive production systems. Fsck is just too fsck'ing slow. :-) On Sun, 2004-01-11 at 14:34, Glenn Burkhardt wrote: > > The reason to use a journalling file system has more to > > do with crash recovery time than with integrity. IMHO, most Unix/Linux > > file systems run without any significant problems for years. > > Crash recovery has been more of an issue at our shop than most, because we use > Unix/Linux in factory equipment. People are turning the power off all the > time without doing a shutdown. Journalling filesystems have been a big plus. > It's such a hassle to try to get a non-computer type to punch in > "fsck -y /dev/sd0a", or something like it. I could never understand the > current reason for requiring a user to type in an fsck command anyway (not > just limited to Linux, Solaris does it, too). I knew one graduate student > when I was in school that would actually repair inodes and recover files, but > I've meet no one else since then that would know what to do. > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://www.blu.org/mailman/listinfo/discuss -- Grant Young <granty at bellatlantic.net>
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |