Re: [PATCH 03/18] xfs: define sparse inode chunks v5 sb feature bit and helper function

From: Brian Foster <bfoster@redhat.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 03/18] xfs: define sparse inode chunks v5 sb feature bit and helper function
Date: Thu, 24 Jul 2014 15:38:26 -0400	[thread overview]
Message-ID: <20140724193825.GE37832@bfoster.bfoster> (raw)
In-Reply-To: <53D1528F.5090906@sgi.com>

On Thu, Jul 24, 2014 at 01:38:07PM -0500, Mark Tinguely wrote:
> On 07/24/14 12:37, Brian Foster wrote:
> >On Thu, Jul 24, 2014 at 12:08:36PM -0500, Mark Tinguely wrote:
> >>On 07/24/14 09:22, Brian Foster wrote:
> >>>The sparse inode chunks feature will use the helper function to enable
> >>>the allocation of sparse inode chunks. The incompatible feature bit is
> >>>set on disk once a sparse inode chunk is allocated to prevent older
> >>>drivers from mounting an fs with sparse chunks.
> >>>
> >>>Note that the feature is hardcoded disabled and the feature bit not
> >>>included in the all features mask until fully implemented.
> >>>
> >>>Signed-off-by: Brian Foster<bfoster@redhat.com>
> >>>---
> >>
> >>Sorry if I missed it in the series but is there an
> >>XFS_FSOP_GEOM_FLAGS_SPINODES for xfs_info/growfs?
> >>
> >
> >Nope, looks like I missed it. It probably slipped my mind as I haven't
> >got into userspace yet and thus hadn't thought about xfs_info. I'll make
> >a note to add it, thanks!
> >
> >Brian
> 
> Again forgive my quick scanning of the series, but am I correct in thinking
> that this does not change the minimum number of reserved blocks for create
> like fs ops. The create/rename do some attempts to continue when it cannot
> get the full number of reserved blocks. Would allocating a sparse inode
> chunk make sense in that case? My gut says the complication does not.
> 

No problem, thanks for looking.

Correct... I haven't made any changes to transaction reservations or
things like XFS_CREATE_SPACE_RES(), etc. xfs_create() has the kind of
logic you describe where we set resblks = 0 if the reservation fails
with ENOSPC and try again with a flag set to indicate we can't do
allocations. My understanding is that this is justified since we could
always allocate an inode from an existing record and a dentry from an
unused slot in a directory.

Technically, I think we could explicitly allocate a sparse chunk in this
scenario if we wanted to, but we'd have to pass that down to/through the
allocation code in xfs_ialloc_ag_alloc(). I could be wrong, but I think
the reservation failure in this case will always be limited to a case
where we are truly up against ENOSPC (as opposed to failing due to an
extent length or alignment requirement), since the reservation comes out
of the sb counters. Given that, I tend to agree that it might not be
worth the extra complexity there.

Brian

> Thanks again,
> 
> --Mark.
> 
> 

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