[zfs-discuss] Issue with data

Joachim Grunwald jgrunwald at ecotronic.de
Thu Sep 26 05:19:13 EDT 2013


Hi Marius and Richard,

Even though using ZFS for more than half a year, I would still call 
myself newbie, so I appreciate any help to understand things. So 
consider that in your replies.

I still have not really understood your point.

I was under the impression, that ashift, just depends on the used 
drives, weather it is ashift=9 (512B) for older drives and for advanced 
drives ashift=12 (4kB).

I have an array with mixed physical block devices (3x512 and 3x4k).
For future expansion (replacing 6x500G with 6x1T) at one point. I 
thought this would be the right setting.

I did set up the pool  "zpool create -o ashift=12 tank raidz2 /dev/sda 
/dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf" and a single drive 2T pool 
"zpool create -o ashift=12 single /dev/sdg"

So according to your explanation the 2G "tank" pool should have less 
usable capacity, than the "single" 2G drive pool?

Is that correct?
What would be the net capacity in my setup for the tank pool?
Or am I thinking the wrong and I should set ashift=14 (16kB) to get 
maximum capacity?

Again apologies if that appears a stupid question.
Joachim


Am 25.09.2013 19:06, schrieb Richard Laager:
> Set your ashift based on the physical parameters of the drive. If you
> have 512B sectors, you *may* want to set ashift to 12 (4kB sectors)
> anyway, out of concerns for replacement drive sector sizes.
>
> Then just be aware that you're going to waste space if your workload
> ends up with ZFS writing blocks of less than (number of data disks) *
> 2^ashift. You asked about a 6-disk raidz2. That has 4 data disks.
> Assuming ashift=12 (4kB disk sectors), that's 4 * 4kB = 16kB. So
> anything less than 16kB blocks will waste space.
>
> Whether you want to accept that trade-off is dependent on what you're
> trying to do and your budget. For example, if you're trying to do all
> 4kB zvols, then your raidz2 effectively becomes a triple-mirror (1x 4kB
> data + 2x parity), so you might as well do triple-mirroring instead. It
> would give you higher read IOPS (as I don't think ZFS special-cases d=1
> raidz stripes to satisfy reads from parity blocks). If you're doing 8kB
> zvols, then it's (2x 4kB data + 2x parity), so you're losing 25% of your
> expected capacity; but if your goal is to survive *any two* drive
> failures, then the only alternative is triple-mirroring, which would
> give you 50% of your expected capacity with the same number and size of
> disks. So that's the same trade-off you already expected, it's just that
> the breakpoint is different.
>
> If you're doing file-based access, keep in mind that recordsize is an
> upper-bound, not a lower-bound. So there's no point in tuning recordsize
> for this.
>


To unsubscribe from this group and stop receiving emails from it, send an email to zfs-discuss+unsubscribe at zfsonlinux.org.



More information about the zfs-discuss mailing list