Dear all, On certain USB MSC dongle, the mkfs.ext3 can take around 3 min for 4GB. It seems that the process is locked in sync function. Do you know how I could increase the speed of this process? With mkfs.ext4 it's about 1 min to format it ... St?phane Cerveau Software Engineer scerveau at awox.com<mailto:scerveau at awox.com> Phone: +33 4 99 53 27 39 93, Pierre Duhem 34000 Montpellier FRANCE Phone: +33 4 67 47 10 00 Fax: +33 4 67 47 10 15 cid:069332510 at 17112008-1528 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/ext3-users/attachments/20110228/02dc53aa/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 16426 bytes Desc: image001.jpg URL: <http://listman.redhat.com/archives/ext3-users/attachments/20110228/02dc53aa/attachment.jpg>
You can speed up mke2fs by reducing the inode count (-i or -N) if your average file size is over 8kB, reduce the journal size (-J size=4) and/or use the lazy_journal_init patch I posted recently, and/or use the lazy_itable_init option. I assume since format performance is important that you do it often and the risk of an uninitialized inode table is low. Or, you could use ext4, which is also faster at runtime, not just format time. Cheers, Andreas On 2011-02-28, at 4:18, Stephane Cerveau <scerveau at awox.com> wrote:> Dear all, > > > > On certain USB MSC dongle, the mkfs.ext3 can take around 3 min for 4GB. It seems that the process is locked in sync function. Do you know how I could increase the speed of this process? > > With mkfs.ext4 it?s about 1 min to format it ? > > > > > > St?phane Cerveau > Software Engineer > > scerveau at awox.com > > Phone: +33 4 99 53 27 39 > > > 93, Pierre Duhem > 34000 Montpellier > FRANCE > Phone: +33 4 67 47 10 00 > Fax: +33 4 67 47 10 15 > > <image001.jpg> > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5913 (20110228) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/ext3-users/attachments/20110228/fb895d2f/attachment.htm>
On Mon, Feb 28, 2011 at 12:18:59PM +0100, Stephane Cerveau wrote:> > On certain USB MSC dongle, the mkfs.ext3 can take around 3 min for > 4GB. It seems that the process is locked in sync function. Do you > know how I could increase the speed of this process? > > With mkfs.ext4 it's about 1 min to format it ...What is the high-level problem that you are trying to solve? Is this for testing purposes? Are you trying to do something for production? Are these dongles new, or do they contain a previously generated ext2/3/4 file system? Depending on the answers to these questions, there are some short-cuts you can take that will speed up mke2fs for ext3, but there are downsides and they aren't safe in all situations (which is why they are not the default). Ext4 has a way to initialize the inode table lazily, after the file system is mounted, which is why it's faster to use mke2fs. - Ted
Stephane Cerveau
2011-Mar-04 10:52 UTC
ext3_free_blocks_sb when removing a more than 1GB file
Dear all, I?m formatting a specific MSC key in ext3. This key sizes 4GB. When I copy a file which is more than 1GB ( 1024MB), I got many errors ?Ext3-fs error ( device sda1): ext3_free_blocks_sb: bit already cleared for block xxxx? when I try to remove it after having sync the copy. Do you know why I could have this kind of error? Why the problem appears only on this kind of key ? What can I do to identify the problem? It seems that there is no error in the FS (e2fsck done successfully) before removing the key. Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/ext3-users/attachments/20110304/fdf8d077/attachment.htm>