Re: [RFC PATCH] Btrfs: add support for inode properties

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 12, 2013 at 8:07 PM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote:
> On Tue, Nov 12, 2013 at 08:04:47PM +0000, Filipe David Manana wrote:
>> On Tue, Nov 12, 2013 at 7:24 PM, Goffredo Baroncelli <kreijack@xxxxxxxxx> wrote:
>> > Hi Filipe,
>>
>> Hi
>>
>> >
>> > On 2013-11-12 14:42, Filipe David Borba Manana wrote:
>> >> This change adds infrastructure to allow for generic properties for
>> >> inodes via a new ioctl.
>> >
>> > I am sure that there is a valid reason, but I was not able to find it:
>> > why implement a new ioctl instead of using the *{set,get)xattr(2) syscall ?
>>
>> Those require one of the following name prefixes: "user.",
>> "security.", "trusted." or "system.". Only "user." can be set from
>> user space and requires no special privileges/capabilities (if you
>> have the necessary permissions on the target inode).
>
>    Why only that limited set? Is that limited by POSIX, or executive
> fiat? Is there any likelihood of us getting an additional namespace?
> (fs.* maybe?)

Good question Hugo.

I have the understanding there's no issue using a new namespace,
perhaps it's not true.
What leads me to think this is that in fact there's one fs which uses
its own custom prefix, hfsplus:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/xattr.h?id=refs/tags/v3.12#n20

And it uses it in fs/hfsplus/xattr.c. I'm now realizing we probably
can use directly the regular setxattr and getxattr code paths in
fs/btrfs/xattr.c and avoid the new ioctls, simplifying things. Will
give it a try.

The vfs path for setting and getting xattrs also doesn't block us from
using xattrs with a new prefix (doesn't use the hfsplus "osx." prefix
constant anywhere).

thanks

>
>    Hugo.
>
>> It could be implemented via the "user." prefix, like
>> "user.btrfs.something" for example - but it can break user
>> applications if they use such prefix already, and we want to validate
>> the values set for such properties too.
>>
>> >
>> > I noticed that you implemented the Compression properties set/get: is
>> > this from "chattr -c" ?
>>
>> With chattr -c you can't specify the compression algorithm - it will
>> use the default (zlib) or the one you specified via mount options.
>>
>> thanks
>>
>> >
>> > [... cut other lines ... ]
>> >
>> > G.Baroncelli
>> >
>
> --
> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
>   PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
>     --- I write in C because using pointer arithmetic lets people ---
>                know that you're virile. -- Matthew Garrett



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux