On 07/12/2015 09:29 AM, Anton Aylward wrote:
On 07/12/2015 08:14 AM, Carlos E. R. wrote:
No, not that.
The idea is, for instance, that if you are going to write a file of 1 megabyte, you assign the space in a single operation, instead of the operating system adding 1 block to the file, one by one, as it is being written. This method reduces the numbers of writes to the inodes a lot.
That's nice to know. Now all we need is a operating system that can peer into the future and see how large a file is going to have to be so that it can allocate the space for it. I can imagine that being useful whether you use MailDir or mbox. </irony>
Seriously though ... The old Software Tools model of a 'cp' program that is based around while (ch = readch(INPUT) { writech(OUTPUT); } isn't going to cut it any more. Even such programs are going to have to be file-system aware if the OS doesn't hide such details from them. Yes I'm perfectly aware that if STDIN gets fstat()'d as a file it can be sized and if STDOUT is a file there will be a ioctl() or something to tell if it can be preallocated. The thing that horrifies me is adding that complexity to all the programs that do anything resembling that. I know that some programs will have to accept 'streaming' input whose size cannot be predetermined. I suspect some applications will preallocated by block regardless of what's coming down the line, such as journalling and logging, knowing full well that eventually the space will be filled. But pushing this down to the individual application level places and undue burden of complexity on the application developer. While I admit to having written device drivers and schedulers and networking code for the kernels of a previous age, I've never looked at file system code. I do admit that the idea of predicting how large a file is going to be with no prior knowledge seems hocus-pocus. The alternative to a 'cp' program that migrates such an application into the kernel seems to violate many long established UNIX principles. it seems to me that if we are to avoid adding complexity to a host of presently exiting and possible future applications, and avoiding precognitive code in the kernel, that having this for the benefit of the few application that can do "walking preallocation", so to speak, like journalling and logging, that *know* they will be using all that space, seems to be adding to the complexity of the file system for the benefit of very few. The power of UNIX and Linux has always been in that, like other physical sciences such as chemistry, it takes a few basic 'elements' and few combinatorial rules and produces a wide range of useful stuff from that. This makes it a contrast to the 'sui generis' approach of OSs that preceded it and many like VMS[1] and Windows, that followed it. The whole point of the UNIX/linux OS is to make things independent of IO. That's why devices are part of the file system hierarchy. There is no "openDevice" as there is in other OSs. For example cp /dev/tty1 ... cp /home/$USER)/.face_icon ... cp /dev/random ... all have the basic "fopen()". There is no "fopen_tty()", "fopen_file()" needed. This is Linux, not something out of IBM or Microsoft. cf Software Tools, and other such white covered books by people such as Richie, Plauger, Pike, Kernigahn, Stevens, Rochkind and Aho. [1] Take, for example, the example of all the different file formats that VMS had. Just look, for example, at the text files. At one project I wrote a script that generated tables that were to be used by the C compiler. The C compiler baulked on them. So I used to editor to find out what was wrong. The editor baulked on them. Eventually I found that that the the type of text file that the editor would accept was different from the type the script generated. Found a program that fixed that. The files looked OK, The C compiler baulked on them still. Eventually I found the output of the editor was a format that was unacceptable to the C compiler. Yes, all this could have been avoided, but its should never have happened in the first place. It would be inconceivable with UNIX/Linux. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org