Messages in this thread | | | Date | Fri, 2 Jan 1998 02:39:06 -0500 (EST) | From | "Albert D. Cahalan" <> | Subject | block devices |
| |
There is a misfeature in drivers/block/ll_rw_blk.c, reported at line 539. It shows up on CD-ROMs mostly, though the FAT code has some very ugly hacks to "fix" related problems and I think the aliasing troubles are related too.
The following error is from mounting a SunOS CD-ROM with UFS: ll_rw_block: device 16:00: only 2048-char blocks implemented (1024)
With the whole filesystem copied (using dd) to a Zip disk: ll_rw_block: device 08:04: only 512-char blocks implemented (1024)
It works from a ramdisk though, so UFS is working. Something is very broken if filesystems need to worry about the physical sector size and alignment.
----- I'll take a (poor?) guess at the solution: -----
Metadata belongs in the page cache, according to the original plans. We could allow 512-byte aligned mappings on all architectures. Read-only unaligned mappings that overlap are no problem. Support for multiple non-page-aligned writers (an uncommon case) involves changing page protection bits as needed to ensure that aliasing problems do not occur.
Example:
process 12 maps a page of /dev/hda process 13 maps a page of /dev/hda3 process 14 maps a page of a file stored on /dev/hda3
The device itself, partition table, and filesystem work together to cause hideous alignment trouble. No problem! (hopefully...) When process 12 writes, the pages with aliasing trouble get marked as temporarily inaccessable in the other processes. When process 13 writes, it gets a page fault. The kernel marks the overlapping page(s) in process 12 as temporarily inaccessable, does a copy, and lets process 13 write. If process 14 has the same alignment as process 13, then it can write too since they share the same page.
| |