Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

interesting note on fsck and journalled filesystems



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org