On Mon, Dec 05, 2011 at 10:46:55AM -0500, Ted Ts'o wrote: > On Mon, Nov 28, 2011 at 03:26:36PM -0800, Darrick J. Wong wrote: > > Record the type of checksum algorithm we're using for metadata in the > > superblock, in case we ever want/need to change the algorithm. > > > > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > In general, it's useful to group changes to the on-disk file system > separately from the other patches, so this should be grouped with the > addition of s_csum_seed (aka c_uuid_csum) in patch #2, and all other > patches that add metadata changes. That way we can see easily what > all of the metadata changes are, at the beginning of the patch, and > make sure that what we have in the e2fsprogs patch set matches what we > have in the ext4 patch set. Ok, I'll reorganize the patches to put all the disk format changes into a separate patch at the beginning of the set. As for e2fsprogs, I think you already committed most of the disk format changes. I'll check the e2fsprogs set. > Also, the change to actually *enable* a file system feature should be > at the very end of the file system. This makes life safer if at some > point in the future we need to do a kernel bisect. If we are > advertising the present of some feature such in /sys/fs/ext4/features, > that should also go at the very end of the patch set (again for > obvious reasons), and it can be grouped with the patch which enables > the feature being defined as being enabled in EXT4_FEATURE_*_SUPP. > (This is really a comment about patch #2 in this series, but I forgot > to mention it in my previous e-mail.) > > A similar set of guidelines apply to patches for e2fsprogs as well. Okay, I'll move the *_SUPP changes into a separate patch at the end of the sets. --D > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
