linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@inwind.it>
To: fdmanana@gmail.com
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH V2] Btrfs: add support for inode properties
Date: Tue, 19 Nov 2013 18:44:27 +0100	[thread overview]
Message-ID: <528BA37B.6050609@inwind.it> (raw)
In-Reply-To: <CAL3q7H6x5_Bh=5yuH0msg3tdomBKQ0RmWmjHcPdSS0yRJChr5Q@mail.gmail.com>

Hi Filipe
On 2013-11-19 17:06, Filipe David Manana wrote:
> On Wed, Nov 13, 2013 at 6:59 PM, Goffredo Baroncelli <kreijack@libero.it> wrote:
>> Hi Filipe,
>>
>> my comments below
>> On 2013-11-13 02:21, Filipe David Borba Manana wrote:
>>> This change adds infrastructure to allow for generic properties for
>>> inodes. Properties are name/value pairs that can be associated with
>>> inodes for different purposes. They're stored as xattrs with the
>>> prefix "btrfs."
[...]
> 
>>
>> Moreover I have a doubt about the opportunity to store the information
>> like the compression both in inode and in the xattr: what happens if the
>> user does an "chattr -c" ? The xattr will be not updated.
> 
> Right, there was no interaction the compression attr/flag.
> The next patch version adds such interaction.
> 
>> I suggest to update/create a real xattr only if there is no space for
>> the new information in the inode. In the other case the xattr should be
>> a fake xattr to get/set the property stored in the inode (or whichever
>> is involved).
>>
>> Of course also the function btrfs_listxattr() should be updated to show
>> the "fake" xattr which doesn't have a real xattr stored on the disk. The
>> same is true for the getxattr() function...
> 
> Adding such fake on the fly stuff seems too complex imho. Just
> adding/removing the xattr compression properties on chattr +c/-c seems
> simpler and more intuitive.


Looking at btrfs_listxattr() it seems that the xattr listing is done in
a very simple way: the function *listxattr() returns a buffer filled
with all the xattr as a zero terminated strings sequences. Because the
"fake" attribute are know in advance, listing these became a memcpy() of
a bytes of buffer statically allocated.

GB

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

  reply	other threads:[~2013-11-19 17:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12 13:42 [RFC PATCH] Btrfs: add support for inode properties Filipe David Borba Manana
2013-11-12 19:24 ` Goffredo Baroncelli
2013-11-12 20:04   ` Filipe David Manana
2013-11-12 20:07     ` Hugo Mills
2013-11-13  0:30       ` Filipe David Manana
2013-11-13  1:21 ` [PATCH V2] " Filipe David Borba Manana
2013-11-13 18:59   ` Goffredo Baroncelli
2013-11-19 16:06     ` Filipe David Manana
2013-11-19 17:44       ` Goffredo Baroncelli [this message]
2013-11-19 16:00 ` [PATCH v3] " Filipe David Borba Manana
2014-01-07 11:47 ` [RFC PATCH v4] " Filipe David Borba Manana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528BA37B.6050609@inwind.it \
    --to=kreijack@inwind.it \
    --cc=fdmanana@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).