Solved [Solved] ZFS configured vs native blocksize

R

russoj88

My plan is to create a zpool on a USB stick for files that I use in between workstations (more of a learning project for ZFS). I can build the pool, filesystems, take snapshots, etc. The drive is a Mushkin 32GB MKNUFDVP32GB.

The issue I'm running into is I get a status message on the pool, "One or more devices are configured to use a non-native block size...". I can see the degraded performance as well. When this USB had NTFS I was getting 25+MB/s writes, but now its around 5 (same machine, same port).

Code: 
# zpool status
  pool: usb-j
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the
        configured block size, or migrate data to a properly configured
        pool.
  scan: none requested
config:

        NAME                              STATE     READ WRITE CKSUM
        usb-j                             ONLINE       0     0     0
          diskid/DISK-070731D3CE442A23p1  ONLINE       0     0     0  block size: 8192B configured, 262144B native

errors: No known data errors
Does this mean the USB has 256K sectors? How can I set that?

Here's the commands I used to build the pool:
Code: 
gpart create -s gpt /dev/da0
zpool create usb-j /dev/diskid/DISK-070731D3CE442A23
Am I missing a step when I make the partition table? I've tried making a partition for the pool as well but same result.
 
Re: ZFS configured vs native blocksize

It's not the partition table, which actually is not needed at all. It is the size of filesystem block used by ZFS.

Use the standard gnop() trick to force 256K blocks. Or if you have 10-STABLE, use sysctl vfs.zfs.min_auto_ashift=18 before creating the pool.
 
Re: ZFS configured vs native blocksize

wblock, thanks for the reply.

Code: 
# gnop create -S 262144 /dev/da0
gnop: secsize is too big.

Is this the correct command to do the trick? I'm on 10-RELEASE.
 
Re: ZFS configured vs native blocksize

ZFS will not accept sector sizes over 8K (ashift of 13)

Code: 
108  /*
109	 * Default maximum supported logical ashift.
110	 *
111	 * The current 8k allocation block size limit is due to the 8k
112	 * aligned/sized operations performed by vdev_probe() on
113	 * vdev_label->vl_pad2.  Using another "safe region" for these tests
114	 * would allow the limit to be raised to 16k, at the expense of
115	 * only having 8 available uberblocks in the label area.
116	 */
117	#define SPA_MAXASHIFT           13

This is probably why zpool status shows 8192B configured. It's read the sector size given by the disk when creating the pool, but been limited by ZFS code to 8k. By the look of the error you posted, gnop() isn't happy about a sector size that big either.

Considering normal disks used 512b sectors until moving to 4k recently, which allowed them to produce bigger disks more easily at the expense of storage efficiency, I'm highly suspect that the USB disk really does use 256k sectors. Small writes and metadata would end up using far too much space.

Just for interest, what does the output of the following look like?

Code: 
diskinfo -v /dev/diskdev
 
Re: ZFS configured vs native blocksize

gnop() limits sector size to the value of of MAXPHYS, which defaults to 128K, but can be overridden in a custom kernel:
Code: 
options MAXPHYS=2097152
That sets 2M for the maximum physical transfer size, which has caused no problems here.

But if ZFS will not use anything larger than 8K, it does not matter. There might be some other way to improve performance on that drive with ZFS. Aligning the partition with 256K would not hurt.
 
Re: ZFS configured vs native blocksize

Code: 
# diskinfo -v /dev/da0
/dev/da0
        512             # sectorsize
        31641829376     # mediasize in bytes (29G)
        61800448        # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        3846            # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
        070731D3CE442A23        # Disk ident.

Is this the correct camcontrol command to identify? I searched for the error and didn't find much at all.
Code: 
# camcontrol identify /dev/da0
camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed

I'm going to try aligning to 256K right now and run some tests to see how it does.

Thanks for the help.
 
Re: ZFS configured vs native blocksize

I ran an unscientific test overnight. I destroyed any pool and partitions, built the partition, pool, and filesystem, and finally copied a file. Here is the script:

Code: 
usbName='usb-j'
deviceName=$1
copyFile='~/PCBSD10.0.3-09-05-2014-x64-DVD-USB.iso'
copyPlace="/$usbName/os"

for i in 1 2 3 ; do
    zpool destroy $usbName
    gpart destroy -F $deviceName
    zpool create $usbName "$deviceName"
    zfs create -o compression=gzip-9 $usbName/os
    echo "No part: ($i)" `time -h cp $copyFile $copyPlace`
done
for partSize in 512 4096 8192 131072 262144 ; do
    for i in 1 2 3 ; do
        zpool destroy $usbName
        gpart destroy -F $deviceName
        gpart create -s gpt $deviceName
        gpart add -t freebsd-zfs -a $partSize $deviceName
        zpool create $usbName "$deviceName"p1
        zfs create -o compression=gzip-9 $usbName/os
        echo "Part size: $partSize ($i)" `time -h cp $copyFile $copyPlace`
    done
done

Code: 
Partition alignment   time  copy-rate
none                        333s   10.24 MBps
512                          372s    9.17 MBps
4096                        354s    9.63 MBps
8192                        333s   10.24 MBps
131072                     420s    8.11 MBps
262144                     395s    8.63 MBps

There was a lot of deviation in the times and I think the drive slowed down significantly because of the heat (almost too hot to hold by the end). I'm going to give lz4 a try, but for what this drive will be performance will not cause such a problem.
 
You must log in or register to reply here.
Back
Top