Given the large number of comments I got (26!), I feel obliged to post a summary of what was said.

First, the problem:
I want to create a large file (let’s say 10 GB) to use as swap space. This file can’t be a sparse file (a file with holes, see wikipedia if you don’t know about sparse files).
Since I’m going to mkswap it, I don’t care about the data that is actually in that file after creating it. The stupid way (but only solution on ext3) to create it is to fill it with zeroes, with is very inefficient.

Theodore Tso provided more information in a comment, which I’m copying here:

Yes, it will work on ext4. A convenient which makes this easy to use can be found here at http://sandeen.fedorapeople.org/utilities/fallocate.c. It was written by Eric Sandeen, a former XFS developer who now works for Red Hat, who has been a big help making sure ext4 will be ready for Fedora and Red Hat Enterprise Linux. (Well, I guess I shouldn’t call him a former XFS developer since he still contributes patches to XFS now and then, but he’s spending rather more time on ext4 these days.)

One warning about the program; it calls the fallocate system call directly, and it doesn’t quite have the right magic architecture-specific magic for certain architectures which have various restrictions on how arguments need to be passed to system calls. In particular, IIRC, I believe there will be issues on the s390 and powerpc architectures. The real right answer is to get fallocate into glibc; folks with pull into making glibc do the right thing, please talk to me.

Glibc does have posix_fallocate(), which implements the POSIX interface. posix_fallocate() is wired to use the fallocate system call, for sufficiently modern versions of glibc.

However, posix_fallocate() is probablematic for some applications; the problem is that for filesystems that don’t support fallocate(), posix_fallocate() will simulate it by writing all zeros to the file. However, this is not necessarily the right thing to do; there are some applications that want fallocate() for speed reasons, but if the filesystem doesn’t support it, they want to receive the ENOSPC error message, so they can try some other fallback — which might or might not involve writing all zero’s to the file.

The other shortcoming with posix_fallocate() is that it doesn’t support the FALLOC_FL_KEEP_SIZE flag. What this flag allows you to do is to allocate disk blocks to the file, but not to modify the i_size parameter. This allows you to allocate space for files such as log files and mail spool files so they will be contiguous on disk, but since i_size is not modified, programs that append to file won’t get confused, and tail -f will continue to work. For example, if you know that your log files are normally approximately 10 megs a day, you can fallocate 10 megabytes, and then the log file will be contiguous on disk, and the space is guaranteed to be there (since it is already allocated). When you compress the log file at the end of the day, if the log file ended up being slightly smaller than 10 megs, the extra blocks will be discarded when you compress the file, or if you like, you can explicitly trim away the excess using ftruncate().

fallocate works fine: creating a 20 GB file is almost immediate. Also, syncing or umounting the filesystem is also immediate, and reading the file returns only zeros. I’m not sure how it is implemented, but it looks nice :-). However, it still doesn’t solve my initial problem: mkswap works, but not swapon:

:/tmp# touch tmp
:/tmp# /root/fallocate -l 10g tmp
:/tmp# ls -lh tmp 
-rw-r--r-- 1 root root 10G Mar  3 11:01 tmp
:/tmp# du tmp 
10485764	tmp
:/tmp# mkswap tmp 
Setting up swapspace version 1, size = 10737414 kB
no label, UUID=a316ce8e-cf33-412b-8dc0-e10d9f2ebdbb
:/tmp# strace swapon tmp
[...]
swapon("/tmp/tmp")                      = -1 EINVAL (Invalid argument)
write(2, "swapon: tmp: Invalid argument\n"..., 30swapon: tmp: Invalid argument
) = 30
exit_group(-1)

(swapon works fine if the file is created normally — without using fallocate()).

Any other ideas?

Dear readers,

I’d like to use a large file (> 10 GB) as swap space.
The required steps are:

1. Create a file
2. mkswap $file
3. swapon $file

Now, how can I create the file? The obvious and fast solution is to create a file with holes:
dd if=/dev/zero of=foo bs=1M count=1 seek=10239
mkswap works, but swapon complains:
# swapon /tmp/foo
swapon: Skipping file /tmp/foo - it appears to have holes.

Of course, I count just dd if=/dev/zero of=foo bs=1M count=10240, but that takes too long for me.

So, question: is there a way to tell the system: create a file that is 10GB big, don’t but fill it with zeros?

The more I think about it, The more I’m convinced that the both approaches that have been proposed to change the way we deal with Debian membership (Joerg’s new statuses for non-developing contributors, and Lars’ counting of advocates) are both steps in the wrong direction.

I really would like something simpler, and less technical, to become a Debian Developer. After all, what matters is that we trust new developers to make the right decisions (for example, not touch something that they are not confortable with). We currently verify that they know each and every technical bit about things that they may never encounter during their DD life, but that doesn’t say anything about their ability to work with others inside a community, or their judgement when touching packages that they don’t maintain.

For example, we could have something inspired by the current process to become a Debian Maintainer: instead of going through 50+ questions, we could rely on advocations from existing Debian Developers to judge new applicants. The advocation wouldn’t simply be “+1” emails (as in Lars’ proposal), but would instead contain a detailed description of what the applicant did. A group of DDs (DAMs, basically) would then read the advocation emails, and decide whether there’s sufficient proof that the applicant can be granted DD status.

That would allow a much faster process, removing the load from the Application Managers and NM Frontdesk Members. And it probably wouldn’t reduce the quality of new DDs, because of the need to collect advocation emails from several DDs.

Probably the best way to move forward with that would be to work on a document (DEP?) that would list all the changes and explain them, and then ask all the developers to vote on it, like it was done for the Debian Maintainers GR. Are there some people interested on working on a first draft of such a document?

So, in the Membership Status GR, we sent a clear message that we wanted those decisions to be postponed. Now, we have a responsibility to prove that we were not just rejecting any change, but that our vote was really a vote against the way those decisions were announced, and/or those particular decisions. I’m convinced that our management of membership needs to be improved.

I hope that in the next weeks/months, we will be able to discuss proposals about membership status. There’s Joerg’s, there’s Lars’, there’s Raphael’s, and there might be other ideas. Ideally, each of them would be discussed and improved separately (because we can’t be expected to agree on one proposal right from the start), and finally we would get to vote on a coherent set of proposals (with an unbiaised ballot ;) to choose in which direction we want to change our management of membership. It would be great to use the DEP process or something similar for that.

It is also interesting to compare this whole story with our current issue: a secretary that ignored valid criticism about a ballot and went on with asking to vote on it. In both cases, someone that is generally trusted and respected by the project made a mistake, and failed to acknowledge it, requiring strong actions from other DDs. I wonder how the secretary crisis will end…