From: John Finlay <finlay@moeraki.com>
To: Andreas Dilger <adilger@enel.ucalgary.ca>
Cc: LVM on Linux <linux-lvm@msede.com>
Subject: Re: [linux-lvm] Re: ext2resize
Date: Tue, 06 Jul 1999 22:27:54 -0700 [thread overview]
Message-ID: <3782E55A.5549A280@moeraki.com> (raw)
In-Reply-To: 199907051947.NAA23523@munet-d.enel.ucalgary.ca
Andreas Dilger wrote:
> John Finlay <finlay@moeraki.com> writes:
> > It seems that ext2 is not really suited for large filesystems: seems like
> > there is too much redundancy in the block groups that causes slow downs in
> > operations like mount, etc.; e2fsck takes hours on a 52GB filesystem.
>
> Actually, the new "sparse superblock" version of ext2 available for Linux 2.2
> kernels removes much of the redundancy issues for superblocks/group blocks.
> Copies are only stored in group 0, and groups which are a power of 3, 5, and
> 7. The real issue with large filesystems isn't the redundancy, which is
> mostly wasted space and slowdown when unmounting, but rather that the fsck
> has to verify the entire FS structure at mount time. The preferred method
It's been my observation that there is an awful lot of disk activity at mount
time on a clean large file system (no fsck). It appears that every superblock is
being written in turn - maybe to set the dirty flag? It's particularly noticeable
if the filesystem uses 1k blocksize. The mounts are much faster for when the
filesystem uses 4k blocksize.
>
> is to have a transaction log/journal which keeps track of outstanding metadata
> changes in progress. When you get a failure, then you only need to replay
> the log to see what parts of the FS were being modified at the time, and
> then only those areas need to be verified at fsck time.
>
Logging metadata does speed up lots of operations including filesystem recovery
after an unclean shutdown by avoiding fsck. This does seem like the only way to
meet the needs of large filesystem users.
>
> > Are there any projects underway to develop a new filesystem that is more
> > suitable for large filesystems?
>
> There are several log FS/JFS projects underway right now for Linux.
Are any of them nearing first release? Where's the best place to find pointers?
>
> Even SGI will release the source (or so I've read) to their IRIX
> filesystem, which is journalled, so this may be added to the mix soon.
>
I'm not hopeful that XFS source will be released soon - seems more like a PR
gesture.
John
next prev parent reply other threads:[~1999-07-07 5:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-07-05 19:47 [linux-lvm] Re: ext2resize Andreas Dilger
1999-07-07 5:27 ` John Finlay [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-07-06 8:56 Lennert Buytenhek
1999-07-06 8:47 Lennert Buytenhek
1999-07-06 7:56 Lennert Buytenhek
1999-07-08 14:34 ` tytso
1999-07-08 22:56 ` Theodore Y. Ts'o
1999-07-05 20:49 Andreas Dilger
1999-07-05 8:47 Lennert Buytenhek
1999-07-05 18:38 ` John Finlay
1999-07-05 18:55 ` John Finlay
1999-07-05 8:40 Lennert Buytenhek
1999-07-04 18:56 Andreas Dilger
1999-06-30 9:46 Admin
1999-07-02 16:58 ` Andreas Dilger
1999-07-05 17:03 ` Stephen C. Tweedie
[not found] <009c01bebee1$aa81b9a0$0102010a@adminstation.sgymsdam.nl>
1999-06-30 7:34 ` Andreas Dilger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3782E55A.5549A280@moeraki.com \
--to=finlay@moeraki.com \
--cc=adilger@enel.ucalgary.ca \
--cc=linux-lvm@msede.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.