xfs
[Top] [All Lists]

Re: [PATCH v2] xfs: probe data buffer from page cache for unwritten exte

To: Jeff Liu <jeff.liu@xxxxxxxxxx>
Subject: Re: [PATCH v2] xfs: probe data buffer from page cache for unwritten extents
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 26 Jun 2012 12:38:00 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4FE85C7B.3010909@xxxxxxxxxx>
References: <4FE85C7B.3010909@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Jun 25, 2012 at 08:41:31PM +0800, Jeff Liu wrote:
> Hello,
> 
> Using the start offset rather than map->br_startoff to calculate the starting 
> page index could
> get more accurate data offset in page cache probe routine.
> With this refinement, the old max_t() could be able to remove too. 
....
> +                     }
> +                     /*
> +                      * xfs_bmapi_read() can handle repeated hole regions,
> +                      * hence it should not return two extents both are
> +                      * holes.  If the 2nd extent is unwritten, there must
> +                      * have data buffer resides in page cache.
> +                      */
> +                     BUG();

That's wrong. A hole can be up to 32bits in length. When the hole is
longer than that, you'll get two extents that are holes. Try working
with sparse files that have holes in the order of a 100TB in them...

Also, as I've said before - BUG() does not belong in filesystem code
that can return an error. Shut the filesystem down with an in-memory
corruption error and maybe put an ASSERT(0) there so debug kernels
trip over it. However, no filesystem "can not happen" logic error is
a reason to panic a production machine.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>