高级格式化硬盘（4k每磁道）在NetBSD

[wkx9dragon]

今天刚读了封电子邮件。是对西数的新硬盘（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..

[leo]

这也太高深了哦！！！！！！！！！！！！！

[lionux]

这么长时间我居然才看到，顶了。

[wkx9dragon]

真服了，netbsd的大神们了，大硬盘问题，居然不是特别严重的问题。据说netbsd 5.1解决了这个问题。
The following reply was made to PR install/42866; it has been noted by GNATS.

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: install/42866: NetBSD 5.0.2 won't install on 1.5 TB hard drive
Date: Tue, 23 Feb 2010 03:36:26 +0700

Date: Mon, 22 Feb 2010 19:55:02 +0000 (UTC)
From: "Randolf Richardson" <randolf@inter-corporate.com>
Message-ID: <20100222195502.14FE463C49F@www.NetBSD.org>

| I've now tried "daily-HEAD 201002210000Z," and sysinst will now
| install on the 1.5 TB hard drive

If you use a NetBSD-5_STABLE release (that which shall become NetBSD 5.1,
one day), I think you'll find that this issue is fixed there as well,
and there you should have no problems with kernel module loading (as in,
there are no kernel modules to load...)

I happen to have had an e-mail exchange with a friend about this very
issue last week - he had the exact same problem, and searched the NetBSD
lists to find that the problem had been reported, and fixed, ages ago,
so he was expecting that 5.0.2 should have had the fix. He was not happy...

However, this fix was (apparently) not considered important enough to
disrupt the (intended to be very stable) NetBSD 5.0 releases, only the
most serious security and operational bugs get fixed there, and not being
able to install on really big filesystems apparently not serious enough t
warrant the change that needed to be made to fix the problem (which always
adds the possibility of the introduction of some other bug).

kre:eek:

[wkx9dragon]

听说NetBSD，block－size 应该小于32kb，我试试在安装一遍。
Re: disappointing upgrade to NetBSD 5.0
Dan Engholm <mustang <at> engholm.org>
2009-06-03 06:16:22 GMT

Manuel Bouyer wrote:
> On Thu, May 28, 2009 at 01:47:59PM -0700, Dan Engholm wrote:
>
>> Manuel Bouyer wrote:
>>
>>> How was your filesystem formatted ? xen3 domU only support 32k MAXPHYS,
>>> so you can't use a ffs with 64k block size ..
>>>
>> Manuel,
>>
>> That's probably it. My ffs is formatted with bsize = 64KiB. Is my only
>> option to reformat to 32KiB or smaller blocks?
>>
>
> Unfortunably yes. Actually this is related to a limitation of the xen3
> xbd interface which doesn't allows 64k requests. The workaround it to
> split 64k requests in 2 32k requests in the domU, and aggregate it again in
> a 64k request in dom0 but that's not implemented yet.
>
>
It took a while but I managed to finally get my upgraded NetBSD 5.0/Xen
3/X.org/X11R7 system back up and running. It was painful but I haven't
lost any data. I still have a few issues to iron out but at least I
have my main machine usable for most tasks again. The 32k block size
limit was the key.

Xen 2 seems to be much less than stable with NetBSD 5.0. That's not too
surprising given its age. I would recommend to everybody still running
Xen 2 to upgrade to Xen 3 before upgrading to NetBSD 5.0, just to take
smaller steps.

Thanks for all the help and advice.

[wkx9dragon]

终于装上了，ffs2文件系统，blcok－size 32kb，没问题。

[lionux]

NetBSD默认安装blcok－size 16k