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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux