At 02:30 16/05/2001, H. Peter Anvin wrote:
>Anton Altaparmakov wrote:
> > And how are you thinking of this working "without introducing new
> > interfaces" if the caches are indeed incoherent? Please correct me if I
> > understand wrong, but when two caches are incoherent, I thought it means
> > that the above _would_ screw up unless protected by exclusive write locking
> > as I suggested in my previous post with the side effect that you can't
> > write the boot block without unmounting the filesystem or modifying some
> > interface somewhere.
>
>Not if direct device acess and the superblock exist in the same mapping
>space, OR an explicit interface to write the boot block is created.
True, but I was under the impression that Linus' master plan was that the
two would be in entirely separate name spaces using separate cached copies
of the device blocks. Putting them into the same cache would make things
work of course, although direct access would probably give you a view of an
inconsistent file system if the fs was writing around the page cache at the
time (unless the fs and direct accesses lock every page on write access,
perhaps by zeroing the uptodate flag on the page).
An explicit interface for the boot block would be interesting. AFAICS it
would have to call down into the file system driver itself (a
read/write_boot_block method in super_operations perhaps?) due to the
differences in how the boot block is stored on different filesystems
(thinking of the "boot block is a file" NTFS case).
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
