On Wed, Jul 22, 2015 at 10:09:23AM +1000, Dave Chinner wrote: > On Tue, Jul 21, 2015 at 01:47:53PM -0400, Mike Snitzer wrote: > > On Tue, Jul 21 2015 at 11:34am -0400, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > > > On 7/20/15 5:36 PM, Dave Chinner wrote: > > > The issue we had discussed previously is that there is no agreement > > > across block devices about whether ENOSPC is a permanent or temporary > > > condition. Asking the admin to tune the fs to each block device's > > > behavior sucks, IMHO. > > > > It does suck, but it beats the alternative of XFS continuing to do > > nothing about the problem. > > Just a comment on that: doing nothing is better than doing the wrong > thing and being stuck with it forever. :) > > > Disucssing more with Vivek, might be that XFS would be best served to > > model what dm-thinp has provided with its 'no_space_timeout'. It > > defaults to queueing IO for 60 seconds, once the timeout expires the > > queued IOs getted errored. If set to 0 dm-thinp will queue IO > > indefinitely. > > Yes, that's exactly what I proposed in the thread I referenced in > my previous email, and what got stuck on the bikeshed wall because > of these concerns about knob twiddling: > > http://oss.sgi.com/archives/xfs/2015-02/msg00346.html > > | e.g. if we need configurable error handling, it needs to be > | configurable for different error types, and it needs to be > | configurable on a per-mount basis. And it needs to be configurable > | at runtime, not just at mount time. That kind of leads to using > | sysfs for this. e.g. for each error type we ned to handle different > | behaviour for: > | > | $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/type > | [transient] permanent > | $ cat /sys/fs/xfs/vda/meta_write_errors/enospc/perm_timeout_seconds > | 300 > | $ cat > | /sys/fs/xfs/vda/meta_write_errors/enospc/perm_max_retry_attempts > | 50 > | $ cat > | /sys/fs/xfs/vda/meta_write_errors/enospc/transient_fail_at_umount > | 1 > > I've rebased this patchset, and I'm cleaning it up now, so in a few > days I'll have something for review, likely for the 4.3 merge > window.... Just thinking a bit more on how to make this simpler to configure, is there a simple way for the filesystem to determine the current config of the dm thinp volume? i.e. if the dm-thinp volume is configured to error out immediately on enospc, then XFS should default to doing the same thing. having XFS be able to grab this status at mount time and change the default ENOSPC error config from transient to permanent on such dm-thinp volumes would go a long way to making these configs Just Do The Right Thing on block dev enospc errors... e.g. if dm-thinp is configured to queue for 60s and then fail on ENOSPC, we want XFS to fail immediately on ENOSPC in metadata IO. If dm-thinp is configured to ENOSPC instantly (i.e. no queueing) then we want XFS to retry and use it's default retry maximums before failing permanently. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
