On Sun, Jan 2, 2011 at 7:55 PM, Adam Borowski <kilob...@angband.pl> wrote: > Note that on the other side of the fence there's something called TxF
Not GA AFAIK. > And what if you're changing one byte inside a 50 GB file? > I see an easy implementation on btrfs/ocfs2 (assuming no other writers), > but on ext3/4, that'd be tricky. My proposal is explicitly only for complete file data updates. >> > what should an application do as a fallback? And given that it is >> >> Fallback could be implement in the kernel or in userland. Using rename >> as a fallback sounds reasonable. Implementations could switch to >> O_ATOMIC when available. > > For large files using reflink (currently implemented as fs-specific ioctls) > can ensure performance. It can give you anything but the abuse for > preserving owner (ie, the topic of this thread). To get that, you'd need > in-kernel support, but for example http://lwn.net/Articles/331808/ proposes > an API which is just a thin wrapper over existing functionality in multiple > filesystems. It basically duplicates an inode, preserving all current > attributes but making any new writes CoWed. If you make the old one > immutable, you get the TxF semantics (mandatory write lock), if you don't, > you'll get the mentioned above "one of the updates will win" data loss. Data loss? If you overwrite a file, losing the old contents isn't data loss. >> > And what are the use cases where this really makes sense? Will people >> >> Lots of files are written in one go. They could all use this interface. > > I don't see how O_ATOMIC helps there. TxF transactions would work (all > writes either succeed together or none does), but O_ATOMIC can't do more > than one file. I mean that each app that writes a file in one go could use the O_ATOMIC API. Extending O_ATOMIC to support multiple files seems simple too by using a vector variant of close. > Uhm, but you didn't answer the question. These two use cases Ted Tso > mentioned are certainly not worth the complexity of in-kernel support, > O_ATOMIC doesn't bring other goodies, and the rest can be done by an > userspace library which is indeed a good idea. Someone is working on such a lib, let's see the code complexity and exceptions it has. >> Not true. I've asked (you) for just such a lib, but I'm still waiting >> for an answer. > > Shachar Shemesh is already working on it, when he finishes, Ted Tso will > point out what's wrong in it (if something is). What else do you need? Don't know yet. Let's wait for that lib. >> Why would anyone work on an implementation if there's no agreement about it? > > Because one implementation after research is better than many naive and > possibly wrong ones. True, but it'd still be nice to have some agreement before doing all that hard work. Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinpqeqrybqtx4avr1aa=t2t04yo5++r0_ynd...@mail.gmail.com
