>> I think the chief question at this level is whether to support the >> "keep the length" flag for fallocate, fdiscard, both, or neither. >> The linux fallocate uses this to allow allocating blocks past EOF, >> which strikes me as nuts; > Why is it bad?
Well, I'm not dholland. But my own answer to that is that it's a _major_ change to Unix filesystem semantics for it to be possible for there to be data after "EOF" (st_size); the nominal file size is no longer the amount of data conceptually stored, nor a cap on the amoutn of data actually stored, nor does it describe the end of that data. (Unless you are going to try to support the proposition that it is possible for a file to have blocks allocated with no contents; storage that does not contain anything is an even more radical departure from traditional semantics.) Of course, there is nothing inherently wrong with changing semantics. But a change this fundamental will affect a _lot_ of the system, far more than just adding posix_fallocate, and should, IMO, be thought out a lot more thoroughly. My own view is that it _is_ nuts, because I can't come up with a coherent paradigm for how it should work. What is the Linux position on the presence of data past st_size? Is it accessible via read()? write()? mmap()? If there are any of those via which it is not accessible, does an ftruncate() call that increases st_size() change that? Is there a way to lower st_size that doesn't free data between the new st_size and the old stsize? ...and the old actual last data? How can one find out the actual distance between the beginning of the file and the end of data? Which command-line tools have been extended to handle such data, and how? What about data before offset 0, before what has traditionally been thought of as the beginning of the file? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B