xfs
[Top] [All Lists]

Re: [PATCH 2/9] xfs: fix incorrect remote symlink block count

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH 2/9] xfs: fix incorrect remote symlink block count
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 30 May 2013 10:46:02 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <51A62F45.5000004@xxxxxxxxxx>
References: <1369636707-15150-1-git-send-email-david@xxxxxxxxxxxxx> <1369636707-15150-3-git-send-email-david@xxxxxxxxxxxxx> <51A62F45.5000004@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, May 29, 2013 at 12:39:33PM -0400, Brian Foster wrote:
> On 05/27/2013 02:38 AM, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > When CRCs are enabled, the number of blocks needed to hold a remote
> > symlink on a 1k block size filesystem may be 2 instead of 1. The
> > transaction reservation for the allocated bloks was not taking this
> > into account and only allocating one block. hence when trying to
> > read or invalidate such symlinks, we are mapping a hole where there
> > should be a block and things go bad at that point.
> > 
> > Fix the reservation to use the correct block count, clean up the
> > block count calculation similar to the remote attribute calculation,
> > and add a debug guard to detect when we don't write the entire
> > symlink to disk.
> > 
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> > ---
> 
> Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
> 
> Unrelated question... I noticed we update di_size in xfs_symlink(). I
> presume this is safe because, even in the non-local case, we actually
> log the data (the path) in the buffers as well, right?

Yes, the remote symlink block allocation and contents is logged in
the same transaction so cwit is safe to update di_size directly and
log that, too.

Cheers,

Dave
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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