Date: Fri, 2 May 1997 09:38:28 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, gibbs@plutotech.com Cc: freeBSD-arch@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG, sos@freefall.freebsd.org Subject: Re: cvs commit: src/sys/scsi sd.c Message-ID: <199705012338.JAA32257@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>So dscheck should do the conversion based on the sector size in the >disklabel? Yes. I'm not sure if we can trust the on-disk value, but drivers set it before calling dsopen() and dsopen() is a good place to convert it to a more convenient form (take log2(d_secsize) and use this for shifts). >Does any of this discussion affect the vn driver? What about being >able to create an ISOFS on a hard drive? Do we only support that via >vn? vn could always use 512-byte "sectors', but it needs to know about the device block size to avoid using the VOP_STRATEGY() interface for non-physical-block requests. It would be useful for debugging for vn to support arbitrary "sector" sizes. I'm not sure if cd9660 on vn works now. I think it does because cd9660 talks to drivers in 512-blocks. >>You also need to constrain file system fragment sizes to a multiple of >>the sector size for a simple implementation. I think only sizes of 512, >>1024, 2048 and 4096 are practical. > >So newfs needs to consult the disklabel and ensure that the frag/block size >is a a power of 2 multiple of the physical sector size in the disklabel. If we limit it to powers of 2. It would be nice to have support for weird sizes as a stream of blocks. I just don't see putting file systems on them. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705012338.JAA32257>