Hi - I am mentoring Adam in this project On Fri, Jun 13, 2008 at 12:51:48PM -0400, Mikulas Patocka wrote: > > If you are rewriting it --- have you somehow thought about avoiding > suspend? > I assume you are talking about handling a suspend of a device underlying the LVM. At the moment, NetBSD does not have the facility to suspend a device in this manner so I dont think we will have this issue (yet). > > A Linux LVM does something like: suspend old table, write to disk with > direct i/o, resume new table. I'd suggest that you invent some method how > to batch these operations into single syscall I think this should be doable with the API that Adam is using - in NetBSD there is a thing called proplib which is a method of passing a very limited form of XML into the kernel - Adam is using proplib to pass the lvm parameters into the kernel. > --- the question --- how to do it portably on all > NetBSD architectures?), Actually, most of the operations you have listed are, from memory, machine independent code - there is very little of the kernel that actually is architecture specific we work hard to keep it that way. > > --- if you port lvm2 as it is, you'll have to audit (and maybe rewrite) > many parts of NetBSD kernel for not waiting for I/O. If you do it badly, > you'll get deadlocks. > The head of the bleeding edge NetBSD code (netbsd-current) is having a lot of work done on it to make the kernel re-entrant and multi-threaded. This may be a bit of a bonus in terms of what you are saying because there should be locks that need to be held to perform the i/o - it may be a case of just making the acquiring of these locks non-blocking (or it may not be an issue at all). We shall need to wait and see on that one. Thanks for the input. -- Brett Lymn "Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer." -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
