linux-ext4 - Re: Uneven load on my raid disks.

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 03 Jan 2011 11:18:59 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Rogier Wolff <R.E.Wolff@...Wizard.nl>
CC:	"Ted Ts'o" <tytso@....edu>,
	Kay Diederichs <kay.diederichs@...-konstanz.de>,
	linux-ext4@...r.kernel.org
Subject: Re: Uneven load on my raid disks.

On 12/30/2010 04:32 AM, Rogier Wolff wrote:
> On Wed, Dec 29, 2010 at 05:17:15PM -0500, Ted Ts'o wrote:
>> On Wed, Dec 29, 2010 at 05:40:12PM +0100, Kay Diederichs wrote:
>>>> says: dumpe2fs -h /dev/md0 | grep RAID
>>>
>>> % tune2fs -l /dev/md0
>>>
>>> ...
>>> RAID stride:              128
>>> RAID stripe width:        768
>>> ...
>>>
>>> runs much faster than dumpe2fs.
>>> The command can also adjust the values.
>>
>> Actually, "tune2fs -l" and "dumpe2fs -h" both run in about the same
>> amount of time.  dumpe2fs without the -h option runs slower than
>> tune2fs -l, true.  But that's because it reads and prints out
>> information regarding the block and inode allocation bitmaps.
> 
> And the annoying thing is that it apparently uses a library function
> that only returns after reading all that data. 
> 
> So while it could print the superblock info and the first few block
> groups, I'm left waiting.
> 
> My remove-of-200-million-files has completed. It took a week. 
> 200000000/7/24/3600 = 330.7 .
> 
> So it deleted around 330 files per second. With one IO operation per
> delete, the four disks operating at close to 75 IOs per second have
> performed reasonable. And at an average of 1 IO per remove, also
> the filesystem has performed reasonable. It seems I forgot the
> -E stride= option on mkfs. 
> 
> The manual of tune2fs hints that this can be tuned after the fact with
> tune2fs. I seriously doubt it. Correct?
> 
> TUNE2FS(8)                                                          
> ...
>        -E extended-options
>               Set extended options for the filesystem.  Extended  options  are
>               comma separated, and may take an argument using the equals ('=')
>               sign.  The following extended options are supported:
> 
>                    stride=stride-size
> ...
>                    stripe_width=stripe-width
> 

It will change the superblock values, but you're right, it does not
appear to actually move around any metadata or inode tables.

Interestingly there are some facilities for doing this if the inode
size gets changed:

/*
 * We need to scan for inode and block bitmaps that may need to be
 * moved.  This can take place if the filesystem was formatted for
 * RAID arrays using the mke2fs's extended option "stride".
 */
static int group_desc_scan_and_fix(ext2_filsys fs, ext2fs_block_bitmap bmap)


-Eric

> 
> 	Roger. 
> 

--
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