On Fri, Jun 07, 2013 at 10:25:40AM +1000, Dave Chinner wrote: > From: Dave Chinner <dchinner@xxxxxxxxxx> > > There are two ways of doing this - the first is to add a CRC to the > remote attribute entry in the attribute block. The second is to > treat them similar to the remote symlink, where each fragment has > it's own header and identifies fragment location in the attribute. > > The problem with the CRC in the remote attr entry is that we cannot > identify the owner of the metadata from the metadata blocks > themselves, or where the blocks fit into the remote attribute. The > down side to this approach is that we never know when the attribute > has been read from disk or not and so we have to verify it every > time it is read, and we must calculate it during the create > transaction and log it. We do not log CRCs for any other metadata, > and so this creates a unique set of coherency problems that, in > general, are best avoided. > > Adding an identifying header to each allocated block allows us to > identify each fragment and where in the attribute it is located. It > enables us to rebuild the remote attribute from just the raw blocks > containing the attribute. It also provides us to do per-block CRCs > verification at IO time rather than during the transaction context > that creates it or every time it is read into a user buffer. Hence > it avoids all the problems that an external, logged CRC has, and > provides all the benefits of self identifying metadata. > > The only complexity is that we have to add a header per fragment, > and we don't know how many fragments will be needed prior to > allocations. If we take the symlink example, the header is 56 bytes > and hence for a 4k block size filesystem, in the worst case 16 > headers requires 1 extra block for the 64k attribute data. For 512 > byte filesystems the worst case is an extra block for every 9 > fragments (i.e. 16 extra blocks in the worse case). This will be > very rare and so it's not really a major concern. > > Because allocation is done in two steps - the first finds a hole > large enough in the attribute file, the second does the allocation - > we only need to find a hole big enough for a worst case allocation. > We only need to allocate enough extra blocks for number of headers > required by the fragments, and we can calculate that as we go.... > > Hence it really only makes sense to use the same model as for > symlinks - it doesn't add that much complexity, does not require an > attribute tree format change, and does not require logging > calculated CRC values. > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> Corresponds to commit d2e448d5fde I see the rework of the remote attribute code later in the series... Reviewed-by: Ben Myers <bpm@xxxxxxx> _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
