From: Jeff D. <jd...@ad...> - 2004-01-28 04:54:53
|
mcm...@ju... said: > above the ubd device is the request queue where the LVM system lives, > it should be possible to have a LVM module that can understand the COW > format, I think it would work best, from what I have seen, as part of > the device mapper LVM, in 2.6 and there is a backport to 2.4 > apparently Ah, that's something I hadn't considered. > Well yes, I want to be able to read real disk images either from a raw > device, yes we could stick in a special case ioctl to check for a real > device and read its geometry but ick it is easier to specify it, or > from a dd'ed image file of a hard disk which would not work even with > the ioctl, so ubd1C102H15S16 is better from my view :) OK, build it and maybe people will come :-) > Um, no the header of the COW is tried first and it was not a multiple > of 512 that is why the raw device broke it tried to read the V2 header > and had a I/O error Yeah, the driver needs to round up to 512 bytes when reading the header. > Ok how about D -- direct (also uppercase) That's going to get confused with O_DIRECT, especially if the memnonic is 'direct'. I was also thing 'd', but it meant 'data'. > Why not, we already have a type field the cow_version why do we need > another integer to express that it is a new format plus the data in > the header changes Because version changes reflect incompatible changes in the format. You bump the version number when old UMLs can't read the new format. When you add ISAM, old UMLs won't be able to read it, but they will still be able to read the normal COW bitmaps. So, this calls for the assignment of a new cow_format, not a new version. > the current variable for ISAM does not really map to anything similar > in a COW file the index and the cow bitmap resemble each other but the > length computation is very different sector count/8 vs sector count*8 > so there is not much code in common between a COW & ISAM how it is > laid out on disk is different, how you find a sector is different, > when you need to update the header is different etc. This means we need to separate out the stuff that's specific to cow_format 0 from what's not. This may require COW V4, but it doesn't call for a new version just for ISAM. > To not follow symlinks like we do now and allow that person who wanted > symlinks pointing to where the backing files are kept to not show up > as fixed paths in the COW file OK, I think that sounds reasonable. > It had not occurred to me that someone would want to generate a COW > file on a mounted system at runtime, but now it seems clear that could > be very useful. > > That is why really I like general solutions, they allow strange things > you did not think of initially to be put in without too much trouble > once it becomes clear why it would be useful. I agree, but I'd like to see at least a plausible use for something before writing it up. > AIO was a pain to auto detect, the compile time check will find it in > some cases where glibc emulates it with threads So libc provides emulation of the aio syscalls, not just aio emulation with its own interface? In that case, the syscalls can be tested with syscall(). > The new request queue has what I think are the JBD barriers sent in > the queue and I was thinking that would be nice to sync when we got > them, much less overhead than the ubd=sync option and it should work > properly with little effort Yeah, that would be a good thing. It would also be a good thing to be able to pass them into the host kernel, so it respects barriers as well. That way we'd get journalling consistency from the UML filesystem down to the host disk without needing to turn on O_SYNC. Jeff |