NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Beating a dead horse



    Date:        Wed, 25 Nov 2015 12:29:15 -0500
    From:        Greg Troxel <gdt%ir.bbn.com@localhost>
    Message-ID:  <rmipoyykmxg.fsf%fnord.ir.bbn.com@localhost>


  | And, there are also disks with native 4K sectors, where the interface to
  | the computer transfers 4K chunks.  That avoids the alignment issue, but
  | requires filesystem/kernel support.  I am pretty sure netbsd-7 is ok
  | with that but I am not sure about earlier.

FFS is OK on NetBSD-7 (not sure about LFS or others, never tried them).
Raidframe might be (haven't looked) but both cgd and ccd are a mess...

I have been looking into cgd, I have exactly that kind of drive, and
want to put CGD on it.   It "works" but counts 4K sectors as if they
were 512 bytes each...  (ie: the cgd is 1/8 the size it should be).
Fixing that the easy way loses all the alignment (and since it is required,
not just inefficient, would probably cause breakage if you're not very very
careful).   Fixing it the right way is hard the way things are right now
(it is real easy to cause panics trying ... I know, been there, done that...)

  | It would probably be possible to add a call into drivers to return this
  | info and propagate it up and have newfs/fdisk query it.

Something like that is a part of what I am thinking about to make cgds
on 4k sector drives work properly (if/when I make cgd work, I'll probably
look at ccds though I have no personal requirement for those, but it
ought to just fall out of the cgd fixes I think).

One real issue, is that on 4K sector discs, things like LABELSECTOR
change meaning (that is, they retain their meaning, but that meaning means
a different thing).   That is, you cannot simply dd a 512 byte/sector
drive to an equivalent sized 4k sector drive and have it have any hope
at all of working - the labels will be in the wrong place, and contain
the wrong data (disklabels on 4k sector drives are kind of unspecified,
but by analogy with MBRs and GPT need to count in units of sectors, not
DEV_BSIZE's)

The one big advantage of 4k sector drives (and the reason I suspect they
exist, as a different species than the drives with emulated 512 byte
sectors) is that they can grow much bigger without blowing the size limits
inherent in 32 bit based labels (like MBRs and disklabels).

That is, while we all have been assuming that for drives > 2TB GPT was
mandatory, it turns out it isn't, disklabels and/or MBR work just fine,
provided the sectors are 4K rather than 512...

I had not been thinking about passing this drive info all the way up to
newfs (and other userland tools) but there's no reason that couldn't be
done.

kre



Home | Main Index | Thread Index | Old Index