Thanks for all the comments and inputs.
feature xattr btrfs-kernel-way
[1] No Yes
[2] No Yes
[3] Yes No
[1]. Ability to read subvol label without mount
[2]. Full-ability to log and track the property
when it is modified
[3]. risk-free patch ?
Any comments on why not the btrfs-kernel-way and a review
of the patch ?
Thanks -Anand
On 11/02/2012 06:49 AM, Fajar A. Nugraha wrote:
On Fri, Nov 2, 2012 at 5:32 AM, Hugo Mills <h...@carfax.org.uk> wrote:
On Fri, Nov 02, 2012 at 05:28:01AM +0700, Fajar A. Nugraha wrote:
On Fri, Nov 2, 2012 at 5:16 AM, cwillu <cwi...@cwillu.com> wrote:
btrfs fi label -t /btrfs/snap1-sv1
Prod-DB-sand-box-testing
Why is this better than:
# btrfs su snap /btrfs/Prod-DB /btrfs/Prod-DB-sand-box-testing
# mv /btrfs/Prod-DB-sand-box-testing /btrfs/Prod-DB-production-test
# ls /btrfs/
Prod-DB Prod-DB-production-test
... because it would mean possibilty to decouple subvol name from
whatever-data-you-need (in this case, a label).
My request, though, is to just implement properties, and USER
properties, like what we have in zfs. This seems to be a cleaner,
saner approach. For example, this is on Ubutu + zfsonlinux:
# zfs create rpool/u
# zfs set user:label="Some test filesystem" rpool/u
# zfs get creation,user:label rpool/u
NAME PROPERTY VALUE SOURCE
rpool/u creation Fri Nov 2 5:24 2012 -
rpool/u user:label Some test filesystem local
Don't we already have an equivalent to that with user xattrs?
Hugo.
Anand did say one way to implement the label is by using attr, so +1
from me for that approach.
--
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
