Messages in this thread | | | Date | Fri, 10 Dec 1999 07:28:48 -0500 (EST) | From | Ingo Molnar <> | Subject | Re: mmap on a device returns ENODEV |
| |
On Fri, 10 Dec 1999, Stephen C. Tweedie wrote:
> As soon as we have <4k-blocksize buffers pinned in this way in the > page cache, we cannot freely relocate those buffers to be page-aligned > with respect to their physical location.
for christ's sake, this is not a RAID5 problem at all. Yes, RAID5 wants to snoop clean block cache state (even if in the pagecache), but it does in no way interfer in the typical case. It does 'hold up' blocks for a short period of time during resynchronization, but you are free to free/relocate those buffers once they got clean. This is nothing new.
> The layering-violation of the soft raid code already means that you > cannot safely run journaling or swap on top of raid 1 or raid 5. One
there is no goddam layering violation. The RAID5 code accesses the buffer (and in the future the page) cache only from system call context, in a well-defined way. If by layering violation you mean 'nobody else can ever look up your goddam buffer', then yes. But thats a bad cache design IMO.
note that even today we already wait for 'users' to go away for freshly allocated blocks, check out unmap_underlying_metadata(). You cannot generally assume that a block is not used by some other subsystem.
i dont know Stephen what your problem is. I thought we agreed on that by defining clean 'dont touch' semantics in the buffer-cache the RAID code and journalling code can do it's thing just fine. I do believe that we can use the (thank god much simplified) buffer-cache to synchronize access to block devices. This is not really hard to do, and i'll do it (soon). It has other advantages too, apart from RAID5 which alone might not bother people.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |