Hours of tiny transfers at the end of a ZFS resilver?
gpalmer at freebsd.org
Mon Feb 15 21:35:10 UTC 2016
On Mon, Feb 15, 2016 at 09:08:43PM +0000, Steven Hartland wrote:
> On 15/02/2016 20:33, Ravi Pokala wrote:
> >> Date: Mon, 15 Feb 2016 21:18:59 +1100
> >> From: Andrew Reilly <areilly at bigpond.net.au>
> >> To: freebsd-fs at freebsd.org
> >> Subject: Hours of tiny transfers at the end of a ZFS resilver?
> >> Message-ID: <120226C8-3003-4334-9F5F-882CCB0D28C5 at bigpond.net.au>
> >> Content-Type: text/plain; charset=us-ascii
> >> Hi Filesystem experts,
> > Hi Andrew,
> > I am in no way, shape, or form a filesystem expert. :-) I *am*, however, an ATA drive expert. I wanted to clarify something you said, because it seems to be a common misunderstanding.
> >> ... the new drives actually have 4096B sectors (although they lie about that in smartctl -i queries):
> > They're not lying.
> >> Sector Sizes: 512 bytes logical, 4096 bytes physical
> > Right there - "Sector Size: ... 4096 bytes physical". This is 512B logical / 4KB physical scheme is called AF-512e, and is a documented, standard format.
> > https://en.wikipedia.org/wiki/Advanced_Format#512e
> > The intent is to allow backwards-compatibility with software going back decades, which only knows about 512-byte sectors. Such software would treat an AF-512e drive the same as any other drive. The trade-off is performance, because the drive has to transparently perform read-modify-write operations (for sub-4096B writes), and read the full 4096B physical sector even if only a single 512B logical sector was requested. (Ditto if a properly-sized but un-aligned request were made.)
> > I know GEOM reports both the logical and physical sector sizes (as the provider's "sectorsize" and "stripesize", respectively), and I know that the ATACAM driver is populating them correctly based on the drive's IDENTIFY_DEVICE information. (My very first submission to the project was to fix some bugs in this code; r262886, 2014-03-07.) [*]
> > I *don't* know if ZFS does the right thing automatically; it might not be able to determine what "the right thing" is in all cases. I leave answering that to the actual ZFS experts. :-)
> Yes this was added nearly 2 1/2 years ago by r254591
It should be noted that ZFS can do the right thing only at pool creation
time. Once the pool has been created the sector size of the underlying
disks is baked in and can only be changed by creating a new pool on
the advanced format disks (or forcing the larger ashift value when
you initially create the pool, even if the disks are really 512 byte
> > -Ravi (rpokala@)
> > [*] This is probably a good segue into discussing why we even have the ADA_Q_4K quirk, and whether we should get rid of it...? --rp
> The 4k quirks exists because a large amount of devices don't report 4k
> correctly instead just reporting 512 for both logical and physical even
> when they are actually 4k or larger physical sector size.
> freebsd-fs at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
More information about the freebsd-fs