lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 16 Sep 2006 18:05:07 +0300 From: "Pavel Mironchik" <tibor0@...il.com> To: "Jan Kara" <jack@...e.cz> Cc: linux-kernel@...r.kernel.org Subject: Re: Fwd: ext2/3 create large filesystem takes too much time; solutions 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 <jack@...e.cz> 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 <jack@...e.cz> > SuSE CR Labs > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists