On Wed, Feb 03, 2010 at 08:53:14PM +0900, Izumi Tsutsui wrote:
> <ufs/ufs/dir.h> says:
> >> * A directory consists of some number of blocks of DIRBLKSIZ
> >> * bytes, where DIRBLKSIZ is chosen such that it can be transferred
> >> * to disk in a single atomic operation (e.g. 512 bytes on most machines).
>
> Probably DEV_BSIZE which could be smaller than physical sector size
> might be able to handle atomic ops, but I wonder if someone actually
> considered how it should work on >DEV_BSIZE sector media.
With physical sectors larger than DEV_BSIZE you are still updating
the directory blocks atomically, but obviously you may change
multiple blocks of DIRBLKSIZ at the same time.
> Is there any working code used on disks with different blocks sizes
> in the past? Probably some code like msdosfs might work, but
> not a whole kernel.
msdofs was 'fixed' some time ago and used on USB media with
different block sizes.
ffs has been designed for different block sizes (but using
native blocks for addressing). On other systems I have used
UFS/FFS derivates (SunOS, Ultrix) with different block sizes
20 years ago.
The original adosfs has been used on media with differnet block
sizes. That doesn't say anything about our implementation, but
different block sizes have been designed in from the beginning.
lfs is pretty complex, I would imagine issues.
cd9660 and ufs have always been used with different block sizes.
If there are issues then with non-2K-block media :)
No idea about nilfs or efs.
Most issues I have seen were not in the main filesystem code
but in the glue that gets it started (i.e. loading superblocks
and deducing parameters from information blocks).
VM code is somewhat unclear to me. While paging from file
objects looks fine, I haven't looked at e.g. the device pager.
> I wondered not only if current code would work or not but also
> how all related APIs had been (or should be) designed and defined.
> FFS sources used both DEV_BSIZE and fs_fsbtodb (or physical sector
> size stored in disklabel) to access disk blocks, and you just "fixed"
> the latter ones as "bugs".
I mainly fixed code that accessed blocks in terms of sector sizes.
The fsbtodb change is just a minor thing, in particular to match
it with the driver API.
> Yes, after fixing one more "bug" which was
> there since initial import ffs seems working on a raw partition on
> 4KB/sect disk, but there are still several sources that pass
> physical block numbers stored in disklabel to I/O functions directly,
> like subr_disk.c etc.
Yes, there is some really weird code originating from some attempt
of writing common code to bootstrap a disklabel, in particular from
systems with MBR. Fortunately that's all in early phases of
booting or accessing disks and as such, well contained.
> --- ufs/ffs/ffs_vfsops.c 31 Jan 2010 10:54:10 -0000 1.256
> +++ ufs/ffs/ffs_vfsops.c 3 Feb 2010 11:07:52 -0000
> @@ -1931,7 +1931,7 @@
> u_int32_t saveflag;
>
> error = ffs_getblk(mp->um_devvp,
> - fs->fs_sblockloc >> (fs->fs_fshift - fs->fs_fsbtodb), FFS_NOBLK,
> + fs->fs_sblockloc / DEV_BSIZE, FFS_NOBLK,
> fs->fs_sbsize, false, &bp);
> if (error)
> return error;
Please commit.
--
Michael van Elst
Internet: mlelstv%serpens.de@localhost
"A potential Snark may lurk in every tree."