some confusion, sorry about that. will get seed-fsid under seeding dir.
(However seeding name was already used by an (upcoming) attribute
(fs_devices->seeding), but now I am thinking seeding as a kobject dir
is better, so will rename the attribute to something else.. like
seeding_flag).
thanks for the feedback.
Thanks, Anand
On 05/21/2015 12:40 AM, David Sterba wrote:
On Tue, Apr 07, 2015 at 04:08:52PM +0800, Anand Jain wrote:
Can I check if this patch set is lined up for the integration branch ?
Any comments ?
I've noticed that the proposal to add an extra directory to the seeding
uuid hasn't been implemented.
http://article.gmane.org/gmane.comp.file-systems.btrfs/43095
"I'm thinking about a representation of the possible relations between
the devices. Seems that the seeding hierarchy for one filesystem is
always linear, so it's ok to represent it by the filesystem UUID chain.
/sys/fs/btrfs/UUID1/UUID2/UUID3
What I still find unsatisfying is lack of any explicit naming attached
to the UUIDs. As we can use lots of types of UUID, saying that "if it
looks like an uuid if the main filesystem directory in sysfs, then it's
the seeding filesystem" is not the best we can come up with.
I don't have a final idea, but at least
/sys/fs/btrfs/UUID1/seeding/UUID2/seeding/UUID3
would look more friendly to the user and also more accssible to
scripting. We coud possibly add other files/dirs to the inserted
directory."
I still think that the plain UUID1/UUID2/... naming scheme is not
acceptable. Yes it is redundant in some way but also more descriptive.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
