[PATCH] mkfile -- create large files efficiently

/mkfile/02-mkfile-sparse: test for creating of sparse file tests/mkfile/03-mkfile-wrong-behavior: tests for incorrect use Signed-off-by: Matej Cepl --- README-prereq |6 +- doc/coreutils.texi| 50 ++- man/mkfile.x |6

mkfile -- create large files efficiently

Hi, I wanted to write this utility which exists on other Unices for some time, but with introduction of posix_fallocate this actually seems make sense now. Eagerly waiting for comments and critcism -- this is my first serious program in C which I make public, so I expect a lot of both ;-). Best

Re: mkfile -- create large files efficiently

On 2009-02-06, 23:37 GMT, Pádraig Brady wrote: > Rather than creating a new utility, prehaps a --preallocate > option to the existing truncate utility would be better? > Especially considering you added a --sparse option to mkfile > which does much the same thing (although not allowing shrinking?).

Re: mkfile -- create large files efficiently

On 2009-02-08, 00:01 GMT, Pádraig Brady wrote: > It wasn't called after the system call. It was called after the > function it was providing. mkfile isn't the best name either BTW. > Also the existing `truncate` command in freebsd which > swayed the choice of name. OK, so what do you suggest to do

[PATCH] Trying to finalize loose ends of truncate.c fallocate

-mkfile: test mkfile(8) Signed-off-by: Matej Cepl --- doc/coreutils.texi|9 man/mkfile.8.xml | 94 + src/mkfile| 81 +++ src/truncate.c| 48

Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate

On 2009-02-27, 14:48 GMT, Pádraig Brady wrote: > Thanks for following this up Matej. > Some very quick comments below. Will review more thoroughly when I've time. Should I send a patch-to-patch or a new one? > I would mention that the main reason for this call is > to ensure blocks are contiguous

[PATCH] Following up on the comments from the upstream

d) * src/truncate.c: rename the option from --fallocate to --allocate nobody is interested in the implementation of the option. Signed-off-by: Matej Cepl --- configure.ac |1 + doc/coreutils.texi |8 +++-- man/mkfile.8.xml | 94 -

Re: mkfile -- create large files efficiently

OK, another turn around of fixes. This is just the last patch, whole branch is available at http://github.com/mcepl/coreutils/tree/truncate-fallocate (repo URL is git://github.com/mcepl/coreutils.git). One note about this patch is that I have unsuccesfully tried to use @bindir@ to have the scrip

Re: [PATCH] Trying to finalize loose ends of truncate.c fallocate

On 2009-02-28, 13:25 GMT, Eric Blake wrote: > Meanwhile, you probably need to clear up your copyright > assignment for both coreutils and gnulib. I will work on the rest of your requirements later (it will take some time), but to this one -- isn't there an automatic assignement for Red Hat empl

Re: mkfile -- create large files efficiently

On 2009-04-03, 10:25 GMT, Pádraig Brady wrote: > I noticed another thread with more info about fallocate: > https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html > > That got me thinking about whether we should use fallocate() > if available in cp etc. so ext4 etc. can allocate

Re: README-prereq update

Pádraig Brady, Tue, 02 Jun 2009 22:49:31 +0100: > I wasn't referring to the update to the automake info, I was warning > about assuming one is using Fedora 11. Yeah, I was trying not-to-promote EOSed Fedora 8. But we should probably not mention any distro version, just required versions of packag

Re: README-prereq update

Eric Blake, Wed, 03 Jun 2009 06:58:02 -0700: >> > I'll update the automake info... >> >> I just pushed this: >> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=ba6e08c > > That's still misleading. Automake 1.11 is a stable release, and distros > are starting to pick it up as such

Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up

Eric Sandeen, Sun, 14 Jun 2009 23:38:34 -0500: > I'd personally rather see a separate, dedicated fallocate tool ... but > maybe that's just me. You might run it by the fsdevel-list, or maybe > I've bike-shedded enough already. :) I still have in my patch and I plan to push into coreutils (if pos

Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up

Pádraig Brady, Sat, 13 Jun 2009 01:19:36 +0100: > I was thinking that truncate --allocate would call posix_fallocate() > which guarantees that the file is allocated even if the filesystem does > not support fallocate(). I.E. we would need to add a posix_fallocate() > gnulib module that adds the fun

Re: [PATCH] Rebasing on Padraig's gnulib fallocate module and cleaning up

Pádraig Brady, Mon, 15 Jun 2009 13:48:47 +0100: > http://www.pixelbeat.org/patches/gnulib-fallocate.diff Could I get a branch of it? I hate following patches... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo

Re: ls manpage incomplete

Richard Guy Briggs, Fri, 10 Jul 2009 07:53:21 -0400: > The standard for documentation has been man for longer than that... It > should be complete. You are right of course, and GNU's insistence on stupid info format is terrible (yes, I hugely prefer manpages over info, even for massive manpages