[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTikZYqbjkTrZPAPFkhMcRnmJtuAzzw@mail.gmail.com>
Date: Sun, 3 Apr 2011 21:52:58 +0300
From: Zeev Tarantov <zeev.tarantov@...il.com>
To: Eric Sandeen <sandeen@...hat.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: problem(?) in ext4 or mke2fs
On Sun, Apr 3, 2011 at 21:40, Eric Sandeen <sandeen@...hat.com> wrote:
> On 4/3/11 11:07 AM, Zeev Tarantov wrote:
>> While testing zram I ran a script that creates a block devices,
>> creates a filesystem on in and untars Qt on that filesystem.
>> I was surprised to find ext4_mb_scan_aligned near the top of the profile output.
>> This was evidently because the command "mke2fs -t ext4 -m 0 -I 128 -O
>> ^has_journal,^ext_attr <block device>"
>> created a filesystem with (output of tune2fs):
>> RAID stride: 1
>> RAID stripe width: 1
>
> mke2fs queries the block device for its geometry, based on what is
> reported via sysfs:
>
> /*
> * Sets the geometry of a device (stripe/stride), and returns the
> * device's alignment offset, if any, or a negative error.
> */
> static int get_device_geometry( ...
> ...
> min_io = blkid_topology_get_minimum_io_size(tp);
> opt_io = blkid_topology_get_optimal_io_size(tp);
> ...
>
> fs_param->s_raid_stride = min_io / blocksize;
> fs_param->s_raid_stripe_width = opt_io / blocksize;
>
> What does
>
> # blockdev --getiomin --getioopt /dev/<yourdevice>
>
> say for your device?
get logical block (sector) size: 4096
get physical block (sector) size: 4096
get minimum I/O size: 4096
get optimal I/O size: 4096
get alignment offset in bytes: 0
get max sectors per request: 255
get blocksize: 4096
get readahead: 256
> The device may be reporting odd values, but mke2fs probably
> should be smart enough not to set block-sized stripe unit and width...
If the filesystem created with the default options is slow or has
higher cpu usage, it should be changed.
> -Eric
-Z.T.
--
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
Powered by blists - more mailing lists