> the low-level APIs involved with file creation. Is there a way to tell > the file system that you´re creating a file with total size "x" before > any such data is written to it, I mean, as part of the file creation > call?. Yes. > I mean, it is one thing to create a file with size 0, then start > appending data to it in chunk, than say "hey, I´m creating a > 8-gigabytes long file, with name xyz". If the latter exists, I´m > curious if there´s logic at the filesystem level to try to find a > chunk of free space big enough to allocate it (to reduce > fragmentation). It would almost certainly be the wrong thing to do to try and create an 8GB chunk in one place, at least when considering the entire system behaviour in the longer term. > downloaded, but I never knew if the file creation call was a single > one or it actually consisted of the file creation call first, and then > a write of the x gigabytes of zeroes... Depends on the filesystem. Unwritten zero blocks in most file systems are not stored but are implied by the file length. > I can´t believe that in this day and age (i briefly looked at the > win32 api and it seems there´s no api to create a fixed-size empty > file) there´s no api for this, and that one has to rely on a per-app > implementation (ie filing zeroes). There is one/ > > Why am I asking this? because of this lament about the lack of a > "mkfile" command in Linux as there is in Solaris > > http://madbodger.livejournal.com/114433.html So find someone more clueful to read ;). mkfile is a solaris command hack. You can do the same on any Unix like os with dd if=/dev/zero of=filename bs=1M count=number-of-megs-you-want I guess mkfile is someones quick wrapper to hide it, or to use fallocate > Just curious... (I know, you will tell me "it isn´t the job of a > filesystem to populate the contents of an empty file!). And maybe > you´d be right. Still, I wonder if perhaps fixed-size, empty-file > creation wouldn´t be much faster if it was implemented at the > filesystem level). Thats why it is. Alan -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
