lkml.org 
[lkml]   [2009]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: spurious -ENOSPC on XFS
    On Mon, Jan 12, 2009 at 06:14:36AM -0500, Mikulas Patocka wrote:
    > Hi
    >
    > I discovered a bug in XFS in delayed allocation.
    >
    > When you take a small partition (52MB in my case) and copy many small
    > files on it (source code) that barely fits there, you get -ENOSPC. Then
    > sync the partition, some free space pops up, click "retry" in MC an the
    > copy continues. They you get again -ENOSPC, you must sync, click "retry"
    > and go on. And so on few times until the source code finally fits on the
    > XFS partition.

    Not a Bug. This is by design.

    > This misbehavior is apparently caused by delayed allocation, delayed
    > allocation does not exactly know how much space will be occupied by data,
    > so it makes some upper bound guess.

    No, we know *exactly* how much space is consumed by the data. What
    we don't know is how much space will be required for additional
    *metadata* to do the allocation so we reserve the worst case need so
    hat we should never get an ENOSPC during async writeback when we
    can't report the error to anyone. Worst case is 4 metadata blocks
    per allocation (delalloc extent, really).

    If we ENOSPC in the delalloc path, we have two choices:

    1. potentially lock the system up due to OOM and being
    unable to flush pages
    2. throw away user data without being able to report an
    error to the application that wrote it originally.

    Personally, I don't like either option, so premature ENOSPC at
    write() time is fine by me....

    > Because free space count is only a
    > guess, not the actual data being consumed, XFS should not return -ENOSPC
    > on behalf of it. When the free space overflows, XFS should sync itself,
    > retry allocation and only return -ENOSPC if it fails the second time,
    > after the sync.

    It does, by graduated response (see xfs_iomap_write_delay() and
    xfs_flush_space()):

    1. trigger async flush of the inode and retry
    2. retry again
    3. start a filesystem wide flush, wait 500ms and try again
    4. really ENOSPC now.

    It could probably be improved but, quite frankly, XFS wasn't designed
    for small filesystems so I don't think this is worth investing any
    major effort in changing/fixing.

    Cheers,

    Dave.
    --
    Dave Chinner
    david@fromorbit.com


    \
     
     \ /
      Last update: 2009-01-13 22:53    [W:0.023 / U:1.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site