25 Sep
2008
25 Sep
'08
3:51 p.m.
On Thu, Sep 25, 2008 at 05:13:25PM -0500, Jules Richardson wrote:
ReiserFS is very handy if one needs plausible deniability for making
inconvenient data disappear. It is _not_ useful for storing data. One
nice stunt: Create a reiserfs. Mount it and create inside that tree
a file that contains a reiserfs image. Umount and to a reiserfsck
--rebuildtree. See your filesystem vanish.
Thre _have_ been people who suggested putting the journal on a ramdisk
for blazingly fast I/O ... and ISTR that back in the days, one could buy
extension cards for SUNs that carried some battery backed RAM for a
similiar purpose (intended for reliably write caching NFS I/O).
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alexander Schreiber wrote:
Yes, that as well. However, the tune2fs utility _does_ exist.
What most journaled file systems gain
you is that you don't need to spend 20 min in fsck after a powerfailure
... or after n reboots, where n is designed to fall at the moment of
maximum incovenience... :-) just less than
a minute in journal rollback.
I tend to run ext3 on any linux system of mine, which seems to do a very
good job at not disappearing up its own backside. I did try reiserfs for a
while until the whole filesystem on my development system decided to eat
itself - never again. Running a
journaled FS on top of flash _greatly_ hastens the demise of
your flash, because of the massive amount (compared to the rest of the
flash) of write traffic the flash blocks in the journal will get. Even
wear leveling can only mitigate that effect so much.
Although at least with ext3 - and probably other journaled filesystems -
you can specify that the journal resides on a completely different device.
How useful that is in practice, I'm not sure - but you don't *have* to have
the journal stored on the same device as the associated data.