---------- Forwarded message ----------
From: Pavel Mironchik <[email protected]>
Date: Sep 12, 2006 2:07 PM
Subject: ext2/3 create large filesystem takes too much time; solutions
To: [email protected]
Hi,
Ext2/3 does erase of inode tables, when do creation of new systems.
This is very very long operation when the target file system volume is more than
2Tb. Other filesystem are not affected by such huge delay on creation of
filesystem. My concern was to improve design of ext3 to decrease time
consuption of creation large ext3 volumes on storage servers.
In general to solve problem, we should defer job of cleaning nodes to
kernel. In e2fsprogs there is LAZY_BG options but it just avoids doing
erase of inodes only.
I see several solutions for that problem:
1) Add special bitmaps into fs header (inode groups descriptors?).
By looking at those bitmaps kernel could determine if inode is not cleaned, and
that inode will be propertly initialized.
2) Add special identifiers into inodes. If super block id != inode id
-> inode is dirty
and should be cleaned in kernel, where super block id is generated on
creation stage.
I choosed second (much easier - just few lines of code)
and implemented patch for e2fsprogs, kernel ext3. It is just proof of a concept.
With the help of this patch I could create terrabytes volumes fast.
Of cource this patch will broke compatibility for existing filesystem.
More correctly is to choose first way and do not broke compatibility.
Writing this mail, I just want check if there is any interest for this problem
from community.
I would like to see that future ext4 filesystem will be created fast.
and I would be appreciate for thoughts, remarks.
---------------------------
Pavel S. Mironchik
--
-----------------------------------
Pavel S. Mironchik
Hello,
> Ext2/3 does erase of inode tables, when do creation of new systems.
> This is very very long operation when the target file system volume is more
> than
> 2Tb. Other filesystem are not affected by such huge delay on creation of
> filesystem. My concern was to improve design of ext3 to decrease time
> consuption of creation large ext3 volumes on storage servers.
> In general to solve problem, we should defer job of cleaning nodes to
> kernel. In e2fsprogs there is LAZY_BG options but it just avoids doing
> erase of inodes only.
>
> I see several solutions for that problem:
> 1) Add special bitmaps into fs header (inode groups descriptors?).
> By looking at those bitmaps kernel could determine if inode is not cleaned,
> and
> that inode will be propertly initialized.
> 2) Add special identifiers into inodes. If super block id != inode id
> -> inode is dirty
> and should be cleaned in kernel, where super block id is generated on
> creation stage.
Hmm, I don't know but how often do you need to create so big
filesystems? My feeling is that one can usually afford to spend some
time with a creation of a filesystem (and it is better to spend it
during creation than to add complexity to the run-time code). Also
having inodes zeroed out is more robust when filesystem is corrupted or
some other nasty thing happens... Just my 2 cents :)
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
Hi Jan,
Probably you are right, but there are lot of competitive filesystems
(reiser,xfs) that do not require such period on creation. I hope at
least Ext4 users will not suffer about that.
Pavel.
On 9/15/06, Jan Kara <[email protected]> wrote:
> Hello,
>
> > Ext2/3 does erase of inode tables, when do creation of new systems.
> > This is very very long operation when the target file system volume is more
> > than
> > 2Tb. Other filesystem are not affected by such huge delay on creation of
> > filesystem. My concern was to improve design of ext3 to decrease time
> > consuption of creation large ext3 volumes on storage servers.
> > In general to solve problem, we should defer job of cleaning nodes to
> > kernel. In e2fsprogs there is LAZY_BG options but it just avoids doing
> > erase of inodes only.
> >
> > I see several solutions for that problem:
> > 1) Add special bitmaps into fs header (inode groups descriptors?).
> > By looking at those bitmaps kernel could determine if inode is not cleaned,
> > and
> > that inode will be propertly initialized.
> > 2) Add special identifiers into inodes. If super block id != inode id
> > -> inode is dirty
> > and should be cleaned in kernel, where super block id is generated on
> > creation stage.
> Hmm, I don't know but how often do you need to create so big
> filesystems? My feeling is that one can usually afford to spend some
> time with a creation of a filesystem (and it is better to spend it
> during creation than to add complexity to the run-time code). Also
> having inodes zeroed out is more robust when filesystem is corrupted or
> some other nasty thing happens... Just my 2 cents :)
>
> Honza
> --
> Jan Kara <[email protected]>
> SuSE CR Labs
>