Re: mmap behavior on out-of-space conditions

[David Chinner]

On Thu, Aug 02, 2007 at 03:06:15PM +0200, Peter Zijlstra wrote:
> On Thu, 2007-08-02 at 14:41 +0200, Petr Tesarik wrote:
> > Hello,
> > 
> > while solving a different issue, my colleague Libor Pechacek found a
> > problem with handling mmapped sparse files. If you mmap the hole insidea
> > sparse file and write to it, the data gets silently lost if there is not
> > enough space left on the underlying device.
> 
> I think Dave's block_page_mkwrite() stuff addresses this as well, no?
> 
> http://lkml.org/lkml/2007/3/18/198

Yes it does. But only XFS hooks that right now. It works, too. ;)

Create and mount 128MB filesystem:

budgie:~ # mkfs.xfs -f -d size=128m /dev/sdb9
....

Fill it up:

budgie:~ # dd if=/dev/zero of=/mnt/scratch/fred bs=1024k count=127
dd: writing `/mnt/scratch/fred': No space left on device
119+0 records in
118+0 records out
124764160 bytes (125 MB) copied, 4.69505 seconds, 26.6 MB/s
budgie:~ # sync
budgie:~ # df -h /mnt/scratch
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb9             124M  120M   48K 100% /mnt/scratch

Free up one block:

budgie:~ # xfs_io -f -c "truncate 124760000" /mnt/scratch/fred
budgie:~ # df -h /mnt/scratch
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb9             124M  120M   52K 100% /mnt/scratch

Create sparse file:

budgie:~ # dd if=/dev/zero of=/mnt/scratch/sparse_mmap_file bs=4k count=1 seek=1000000000
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.00022675 seconds, 18.1 MB/s
budgie:~ # ls -l /mnt/scratch/sparse_mmap_file
-rw-r--r-- 1 root root 4096000004096 Aug  3 08:13 /mnt/scratch/sparse_mmap_file

Mmap sparse file and try to write to it:

budgie:~ # xfs_io -f -c "mmap 0 1000000000" -c " mwrite 4000000 50000" /mnt/scratch/sparse_mmap_file
Bus error

There's your bus error. The blocks that were allocated before ENOSPC:

budgie:~ # xfs_bmap -vp /mnt/scratch/sparse_mmap_file
/mnt/scratch/sparse_mmap_file:
 EXT: FILE-OFFSET               BLOCK-RANGE      AG AG-OFFSET             TOTAL
   0: [0..7807]:                hole                                       7808
   1: [7808..7839]:             155520..155551    4 (24448..24479)           32
   2: [7840..7999999999]:       hole                                 7999992160
   3: [8000000000..8000000007]: 155512..155519    4 (24440..24447)            8
budgie:~ #

We got 4x4k data blocks allocated and:

budgie:~ # df -h /mnt/scratch
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb9             124M  120M   32K 100% /mnt/scratch

That shows that 5 blocks were allocated to hold the 4 data blocks
that lead to ENOSPC. i.e. a metadata block of some kind was also
allocated.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/