On Mon, Jan 3, 2011 at 4:25 AM, Ted Ts'o <ty...@mit.edu> wrote: > On Sun, Jan 02, 2011 at 04:14:15PM +0100, Olaf van der Spek wrote: >> >> Last time you ignored my response, but let's try again. >> The implementation would be comparable to using a temp file, so >> there's no need to keep 2 g in memory. >> Write the 2 g to disk, wait one day, append the 1 k, fsync, update inode. > > Write the 2g to disk *where*? Some random assigned blocks? And using
A random allocation strategy would work, but better options are available. ;) > *what* to keep track of the where to find all of the metadata blocks? Implementation detail, but a new temp inode might work. > That information is normally stored in the inode, but you don't want > to touch it. So we need to store it someplace, and you haven't > specified where. Some alternate universe? Another inode, which is > only tied to that file descriptor? That's *possible*, but it's (a) > not at all trivial, and (b) won't work for all file systems. It > definitely won't work for FAT based file systems, so your blithe, "oh, > just emulate it in the kernel" is rather laughable. You'd have to decide what you want to do in that case. One option is to fallback to the non-atomic variant. Another is to fallback to a temp file with a name. But then I assume the kernel is still able to preseve meta-data and to ensure atomic operation. > If you think it's so easy, *you* go implement it. > >> > How exactly do the semantics for O_ATOMIC work? >> > >> > And given at the momment ***zero*** file systems implement O_ATOMIC, >> > 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. > > Using rename as a fallback means exposing random temp file names into > the directory. Which could conflict with files that the userspace > might want to create. They don't need to be in the same dir. > It could be done, but again, it's an awful lot > of complexity to shove into the kernel. That's unfortunate but I think the only option. >> > highly unlikely this could ever be implemented for various file >> > systems including NFS, I'll observe this won't really reduce >> > application complexity, since you'll always need to have a fallback >> > for file systems and kernels that don't support O_ATOMIC. >> >> I don't see a reason why this couldn't be implemented by NFS. > > Try it; it should become obvious fairly quickly. Or just go read the > NFS protocol specifications..... In that case: update the NFS protocol (yes, long-term solution) >> As you've said yourself, a lot of apps don't get this right. Why not? >> Because the safe way is much more complex than the unsafe way. APIs >> should be easy to use right and hard to misuse. With O_ATOMIC, I feel >> this is the case. Without, it's the opposite and the consequences are >> obvious. There shouldn't be a tradeoff between safety and potential >> problems. > > Application programmers have in the past been unwilling to change > their applications. Why not? > If they are willing to change their applications, > they can just as easily use a userspace library, or use fsync() and > rename() properly. If they aren't willing to change their programs Fsync, rename (and preserving meta-data) is a lot more complex then their current code which for me would be a disadvantage. O_ATOMIC is a single flag that doesn't increase their code complexity. A new lib dependency is also a disadvantage. > and recompile (and the last time we've been around this block, they > weren't; they just blamed the file system), asking them to use > O_ATOMIC probably won't work, given the portiability issues. If they're happy to blame the FS they're probably also happy to #define O_ATOMIC 0 if O_ATOMIC isn't available. >> Not true. I've asked (you) for just such a lib, but I'm still waiting >> for an answer. > > Pay someone enough money, and they'll write you the library. Whining > about it petulently and expecting someone else to write it is probably > not going to work. Given that the issue has come up before so often, I expected there to be a FAQ about it. I didn't say you had to write such a lib, just saying you weren't aware of any existing lib would've been enough. But given that you have so much experience on this issue, pointing to a few apps that got this right shouldn't be so hard. Unless getting it right is currently impossible... > Quite frankly, if you're competent enough to use it, you should be > able to write such a library yourself. If you aren't going to be > using it yourself, they why are you wasting everyone's time on this? Because this is still a real world problem that needs to be solved. Stopping this conversation isn't going to solve the problem. 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/aanlktinnfknig=yank75fh4g2atuepbgsv1awrqgd...@mail.gmail.com
