On Wed, Jan 07, 2015 at 08:08:50PM +0100, Martin Steigerwald wrote: > Am Dienstag, 6. Januar 2015, 15:03:23 schrieb Zygo Blaxell: > > ext3 has a related problem when it's nearly full: it will try to search > > gigabytes of block allocation bitmaps searching for a free block, which > > can result in a single 'mkdir' call spending 45 minutes reading a large > > slow 99.5% full filesystem. > > Ok, thats for bitmap access. Ext4 uses extens. ...and the problem doesn't happen to the same degree on ext4 as it did on ext3. > > So far I've found that problems start when space drops below 1GB free > > (although it can go as low as 400MB) and problems stop when space gets > > above 1GB free, even without resizing or balancing the filesystem. > > I've adjusted free space monitoring thresholds accordingly for now, > > and it seems to be keeping things working so far. > > Just to see whether we are on the same terms: You talk about space that BTRFS > has not yet reserved for chunks, i.e. the difference between size and used in > btrfs fi sh, right? The number I look at for this issue is statvfs() f_bavail (i.e. the "Available" column of /bin/df). Before the empty-chunk-deallocation code, most of my filesystems would quickly reach a steady state where all space is allocated to chunks, and they stay that way unless I have to downsize them. Now there is free (non-chunk) space on most of my filesystems. I'll try monitoring btrfs fi df and btrfs fi show under the failing conditions and see if there are interesting correlations.
Attachment:
signature.asc
Description: Digital signature
