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@xxxxxxxxxx> > >>>--- > >> > >>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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
