linux-ext4 - Re: [PATCH 3/3] Add inode table initialization code into Ext4

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1008251444590.2840@dhcp-lab-213.englab.brq.redhat.com>
Date:	Wed, 25 Aug 2010 15:00:46 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Andreas Dilger <adilger@...ger.ca>
cc:	Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org,
	rwheeler@...hat.com, sandeen@...hat.com, jack@...e.cz,
	tytso@....edu
Subject: Re: [PATCH 3/3] Add inode table initialization code into Ext4

On Wed, 25 Aug 2010, Andreas Dilger wrote:

> On 2010-08-24, at 03:01, Lukas Czerner wrote:
> > On Mon, 23 Aug 2010, Andreas Dilger wrote:
> >> 
> >> On that related note, it may make sense to handle the itable zeroing for all filesystems from a single thread, instead of possibly starting multiple threads all writing to the same block device and causing a lot of seeking.  That means that at thread startup time it should verify that only a single thread is started, and all registered filesystems should put their zeroing tasks onto a list (under spinlock) that the one thread checks before it exits.

I Agree.

> > 
> > So you are suggesting filesystem independent threat which can be used by
> > any filesystem on any block device ? I really do not know, if other file
> > systems will be interested in it.
> 
> No, I just mean for ext4 filesystems, not other types of filesystems.  What I'm thinking about is that a system gets newly installed with 3 or 4 ext4 filesystems (/, /var, /home, /usr) in LVM or partitions on the same disk.  If we have multiple zeroing threads going on the same disk at one time it will be slow and seeking, and will significantly impact interactive performance.

That sounds good to me. Thanks.

> 
> > One problem that might emerge when we have one thread for multiple
> > devices is, that it can be fairly complicated to control the thread
> > according to device load. So it might be better to have one thread per
> > device (disk). But it is just my first guess, since I need to look more
> > into it.
> 
> While one thread per disk would possibly be faster, I don't think this is a critical performance issue, and determining the filesystem-to-disk mapping is complex and not easily done.  Having a single thread initialize the inode tables in series (one filesystem at a time) is fine, and it only needs to control the device load for a single filesystem.
> 
> Cheers, Andreas

Ok, doing one file system at a time seems reasonable, but in this case
mkfs should really zero out at least some of the inode tables, so we
have some reserve before the thread reach the next file system.

However, I think we might have a problem when there are more really big
filesystems, so at the end we will surely need to do some optimization
like "when there is too much traffic on one device, try another", or
"round-robin".

Regards.
-Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html