On Tue, 22 Apr 2008, Chris Mason wrote: > I'm definitely willing to include it for you to experiment with. Holding a > transaction from userland can indeed lead to deadlock, but in this case your > userland basically owns the server anyway. I'm worried about some nasty > corner cases still, but btrfs is blissfully ignoring those right now anyway. > > One problem will be operations that are basically boundless (truncating a > file, large writes). Eventually the ENOSPC support will hook into the > transaction system to make sure a given operation reserves enough free space. > > With your ioctls, the "do a bunch of stuff" will need to honor the same > accounting rules as the kernel code (which don't exist yet). So, if the transaction start ioctl made a space reservation, and if _all_ fs ops were wrapped by such reservations, that should avoid ENOSPC, yeah? That's doesn't really help with the memory pressure issue, though. :( > I thought your original plan was to do all of this from userland (without a > kernel filesystem at all)? The btrfs progs share most of the same code with > the kernel, so with a little love to the transaction and IO subsystems, you'd > be able to use it as a library style DB. Yeah... The issue is just that "a little love" is significantly more love than this handful of ioctls, and I'm a little wary of getting into it. That does seem like a better long term solution, though. sage -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
