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. > > 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
