lkml.org 
[lkml]   [1998]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectblock 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.


\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.028 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site