On Mon, Sep 02, 2019 at 10:43:04PM +0800, Gao Xiang wrote: > Hi Christoph, > > > ... > > > 24 __le32 features; /* (aka. feature_compat) */ > > > ... > > > 38 __le32 requirements; /* (aka. feature_incompat) */ > > > ... > > > 41 }; > > > > This is only cosmetic, why not stick to feature_compat and > > feature_incompat? > > Okay, will fix. (however, in my mind, I'm some confused why > "features" could be incompatible...) The feature is incompatible if it requires changes to the driver. An easy to understand historic example is that ext3 originally did not have the file types in the directory entry. Adding them means old file system drivers can not read a file system with this new feature, so an incompat flag has to be added. > > > > > + memcpy(&sb->s_uuid, layout->uuid, sizeof(layout->uuid)); > > > > > + memcpy(sbi->volume_name, layout->volume_name, > > > > > + sizeof(layout->volume_name)); > > > > > > > > s_uuid should preferably be a uuid_t (assuming it is a real BE uuid, > > > > if it is le it should be a guid_t). > > > > > > For this case, I have no idea how to deal with... > > > I have little knowledge about this uuid stuff, so I just copied > > > from f2fs... (Could be no urgent of this field...) > > > > Who fills out this field in the on-disk format and how? > > mkfs.erofs, but this field leaves 0 for now. Is that reasonable? > (using libuuid can generate it easily...) If the filed is always zero for now please don't fill it out. If you decide it is worth adding the uuid eventually please add a compat feature flag that you have a valid uuid and only fill out the field if the file system actualy has a valid uuid.
