Date: Thu Apr 18 13:45:37 PDT 2002
Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea
If you make a 50M filesystem and copy a kernel tree to it, you'll see
that after you run out of space on the copy, 15M-20M of space magically
re-appears after a sync. This is because the worst-case space requirement
for metadata is reserved for delayed writes, and when these are finally
flushed, much of that space is reclaimed. (Thanks, Steve!)
There is a loop in xfs_bmap that tries to deal with ENOSPC, which
tries progressively harder to shake loose some space. The last thing
it tries is VFS_SYNC, but this wasn't syncing the data buffers.
Changing this to fsync_no_super does the trick.
The following file(s) were checked into:
bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
Modid: 2.4.x-xfs:slinx:116769a
linux/fs/xfs/linux/xfs_lrw.c - 1.132
- In the ENOSPC loop in xfs_bmap, sync the data buffers, so that
the worst-case reserved metadata space for delayed writes
will be freed, and we can truly fill the filesystem.
|