| To: | "Darrick J. Wong" <darrick.wong@xxxxxxxxxx> |
|---|---|
| Subject: | Re: fallocate mode flag for "unshare blocks"? |
| From: | Dave Chinner <david@xxxxxxxxxxxxx> |
| Date: | Thu, 31 Mar 2016 12:18:13 +1100 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, linux-btrfs <linux-btrfs@xxxxxxxxxxxxxxx>, linux-api@xxxxxxxxxxxxxxx |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20160330182755.GC2236@xxxxxxxxxxxxxxxx> |
| References: | <20160302155007.GB7125@xxxxxxxxxxxxx> <20160330182755.GC2236@xxxxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Wed, Mar 30, 2016 at 11:27:55AM -0700, Darrick J. Wong wrote: > Or is it ok that fallocate could block, potentially for a long time as > we stream cows through the page cache (or however unshare works > internally)? Those same programs might not be expecting fallocate to > take a long time. Yes, it's perfectly fine for fallocate to block for long periods of time. See what gfs2 does during preallocation of blocks - it ends up calling sb_issue_zerout() because it doesn't have unwritten extents, and hence can block for long periods of time.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx |
| Previous by Date: | Re: [PATCH v1 2/8] block: make 'struct bvec_iter' not depend on CONFIG_BLOCK, Ming Lei |
|---|---|
| Next by Date: | Re: [PATCH] xfs/030: link .out file according to reflink support status, Dave Chinner |
| Previous by Thread: | Re: fallocate mode flag for "unshare blocks"?, Liu Bo |
| Next by Thread: | Re: fallocate mode flag for "unshare blocks"?, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |