Crispin Cowan wrote:
> Marc Lehmann wrote:
>
> > On Mon, Jul 31, 2000 at 12:14:34AM +0200, Xuan Baldauf <baldauf@medium.net> wrote:
> > > spindown of (IDE) disks. There will be a call to sync() after 32 or less
> > > seconds have elapsed since the last sync(). Not a problem itself, but
> > > every sync spins up the disk again.
> >
> > Which is normal and definitely not reiserfs-dependent.
>
> Noted. cc to reiserfs mailing list deleted.
>
> > As for some hint: use "noflushd" (try freshmeat). With that, you don't loose
> > atime (which is very important for many things, like /tmp cleanup) and your
> > disks still do not spin up.
> >
> > I use it on my answering machine, and unless I receive e-mail (fsync ;), or
> > the memory cache is full (very rare, as i receive lots of e-mail), the disks
> > stay down.
> >
> > At night, when I don't route mail to my machine, the disks are usually down
> > for hours.
>
> How much risk of a corrupted file system do you get from this approach? I'd like to
> spin down my HD on my laptop, but I REALLY depend on this machine as my primary
> workstation, so I'd rather not lose the FS ;-)
>
> Crispin
>
> --
> Crispin Cowan, Chief Scientist, WireX Communications, Inc. http://wirex.com
> Free Hardened Linux Distribution: http://immunix.org
When using reiserfs, the risk to crash the filesystem with this approach compared to the
general risk is zero, because the journaling is always done entirely, or never. The time
between a transaction completes is irrelevant. (Of course your file system metadata
state might be reset to the state of hours ago.) AFAIK, all journaling data is sync()
like hurried to disk without leaving kflushd to choose to do that sometimes later. So
you should get you filesystem in a nearly always consistent and current state, but all
writes to files after that which do not trigger a sync() will be lost. (So you can loose
data, but not metadata).
Xuân. :o)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:05 EST