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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
