Re: atomicity

Torbjorn Lindgren (tl@fairplay.no)
Mon, 7 Dec 1998 23:12:58 +0100 (CET)


On Mon, 7 Dec 1998, [iso-8859-1] Johnny Teveßen wrote:
> Quoting Florian Weimer (fw@cygnus.stuttgart.netsurf.de):
> > If that fragments your file system, then don't do that. That's the
> > reason why you should only use about 90% of the total capacity of an
> > ext2fs
>
> Nice said. My filesystems (6) are all between 96 and 100%. I'd like
> to have them fragmented.

Unless you have retuned the filesystem all the normal utilities will show
that the filesystem is 100% full at 95%...

Anyway, it's isn't THAT hard to get high amount of fragmentation even
without changing this, the worst I have seen was something like *85%* if I
remember it correctly!

And this wasn't some contrieved test, I just happened to glance at the
line it printed when it had fsck'd that RAID-0 array.. Yes, I was a bit
surprised, to say the least... (the filesystem is fairly full, but it has
never been into the super-user only 5%)

I think it's time to retrieve a new version of defrag, and let it at the
25 GB ext2 filesystem (for extfs/ext2fs/minix/xiafs)... I have to wait to
a time when it can be offline for a LONG time first though, which is why I
haven't done something about it yet.

That, and the fact that it looks like it'll need something like *450* MB
of memory for tablespaces alone for a 25 GB filesystem if one believe the
comments in the README file (defrag-0.73, for extfs/ext2fs/minix/xiafs).
The machine doesn't have that much memory+SWAP! at the moment, fortunately
the 32 GB filesystem on the same machine isn't badly fragmented (different
usage patterns)...

Should probably add memory (up to 512MB) before doing THAT exercise. Yeah,
a backup before starting is probably a good idea too...

Hmmm... With 3 GB max per-process VM (i386 default, right?) defrag
would max out somewhere in the 170 GB area if this is correct (8B/block +
8B/inode), for filesystems with 512-byte blocks and one inode per 4096
bytes.... In this case most of it are for the block map (8/9 of the
memory).

Larger blocks would cut this down somewhat (~1.5TB for 8k block and one
inode per 8192 bytes, with 50/50 usage), but 64-bit hardware really looks
inviting..

-
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/