高级格式化硬盘(4k每磁道)在NetBSD
发表于 : 2010-02-25 15:37
今天刚读了封电子邮件。是对西数的新硬盘(4k每磁道)的讨论。我的英文不咋地,基本理解是由于历史问题,好多软件都假设每磁道512字节,所以BSD系统到目前为止没有完美的解决办法。粗超的方法是。用newfs -S 命令。
原文:
> Does newfs automatically choose 4k fragment sizes for new drives with 4k
> >sectors?
Sort of. Currently you need to specify the sector size with -S. Fragment
and block sizes are validated or selected automatically.
> >I'm wondering how much fallout there will be when these drives become more
> >common.
Most of these drives will just work, you just treat them as old 512byte-
per-sector-disks. As you read in the article, you need to be careful about
partitioning to avoid the alignment issues.
Jason Thorpe wrote:
> > On Jan 13, 2010, at 3:57 AM, Izumi Tsutsui wrote:
> >
>> > > As I wrote first, we should make a decision of buffercache(9)
>> > > and physio(9) APIs for !512bytes/sector disks.
>> > > Fixing file systems or disk drivers without it just generates
>> > > yet another random inconsisntent patch because there is no "right" fix.
>> > > We have to consider which should be used hardware sector size or
>> > > min I/O size everywhere DEV_BSIZE and "disk block (fsbtodb, blkno etc)"
>> > > are referred.
> >
> > My preference would be to have the devices themselves report
> > the physical block size to be used, and to refer to that value
> > throughout the storage stack when performing I/O do that device.
> > I think the DEV_BSIZE constant should go away.
I also prefer it, but an annoying problem is that we already have
too many sources that assume I/O size is DEV_BSIZE constant.
How do you think about disk_blocksize() in kern/subr_disk.c and
DK_BSIZE2BBLKSHIFT() macro in <sys/disk.h>, for example?
What about "if (lp->d_secsize == DEV_BSIZE)" checks in
sys/dev/scsipi/sd.c:sdstrategy() and sys/dev/ata/wd.c:wdstrategy() etc?
What should we do for all use of btodb() and dbtob() macro
in file system code?
Does "disk block" in file system sources mean unit of
physical block size (that would be variable), or
logical one (I/O size defined by the OS)?
> > Perhaps you should write up a proposal to float by Core?
Well, I think it was proposed and asked in PR 3790, 3791, and 3792
by the late Koji Imada, back in 1997. I discussed with him about
this issue, but I didn't have knowledge about kernel development
at all in those days..
原文:
> Does newfs automatically choose 4k fragment sizes for new drives with 4k
> >sectors?
Sort of. Currently you need to specify the sector size with -S. Fragment
and block sizes are validated or selected automatically.
> >I'm wondering how much fallout there will be when these drives become more
> >common.
Most of these drives will just work, you just treat them as old 512byte-
per-sector-disks. As you read in the article, you need to be careful about
partitioning to avoid the alignment issues.
Jason Thorpe wrote:
> > On Jan 13, 2010, at 3:57 AM, Izumi Tsutsui wrote:
> >
>> > > As I wrote first, we should make a decision of buffercache(9)
>> > > and physio(9) APIs for !512bytes/sector disks.
>> > > Fixing file systems or disk drivers without it just generates
>> > > yet another random inconsisntent patch because there is no "right" fix.
>> > > We have to consider which should be used hardware sector size or
>> > > min I/O size everywhere DEV_BSIZE and "disk block (fsbtodb, blkno etc)"
>> > > are referred.
> >
> > My preference would be to have the devices themselves report
> > the physical block size to be used, and to refer to that value
> > throughout the storage stack when performing I/O do that device.
> > I think the DEV_BSIZE constant should go away.
I also prefer it, but an annoying problem is that we already have
too many sources that assume I/O size is DEV_BSIZE constant.
How do you think about disk_blocksize() in kern/subr_disk.c and
DK_BSIZE2BBLKSHIFT() macro in <sys/disk.h>, for example?
What about "if (lp->d_secsize == DEV_BSIZE)" checks in
sys/dev/scsipi/sd.c:sdstrategy() and sys/dev/ata/wd.c:wdstrategy() etc?
What should we do for all use of btodb() and dbtob() macro
in file system code?
Does "disk block" in file system sources mean unit of
physical block size (that would be variable), or
logical one (I/O size defined by the OS)?
> > Perhaps you should write up a proposal to float by Core?
Well, I think it was proposed and asked in PR 3790, 3791, and 3792
by the late Koji Imada, back in 1997. I discussed with him about
this issue, but I didn't have knowledge about kernel development
at all in those days..