linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Samuel <chris@csamuel.org>
To: linux-btrfs@vger.kernel.org
Subject: Re: Can BTRFS handle XATTRs larger than 4K?
Date: Mon, 22 Dec 2014 22:38:04 +1100	[thread overview]
Message-ID: <3748928.v6JPJNQWc6@quad> (raw)
In-Reply-To: <CAJCQCtQV3tQZ0WpTt0k3geKUfDJ23EDskyxDCTqkx0FFrSWCsA@mail.gmail.com>

On Sat, 20 Dec 2014 01:38:43 AM Chris Murphy wrote:

> I'm feeling too lazy to actually go look for evidence of this; but I
> made a file system a while ago with 64KB node/leafsize and ran into a
> bug I reported for send/receive. I'm pretty sure this was related to
> xattr being limited to nodesize, and I'm also pretty sure it got
> fixed. But I'm not sure whether the problem was on the send or receive
> side, and I'm not sure when.

I suspect it's this commit and it implies that it's limited to the leafsize:

commit 4395e0c4da486f007dcb45b0336427be7ec08ab1
Author: Filipe Manana <fdmanana@suse.com>
Date:   Wed Aug 20 10:45:45 2014 +0100

    Btrfs: send, lower mem requirements for processing xattrs
    
    Maximum xattr size can be up to nearly the leaf size. For an fs with a
    leaf size larger than the page size, using kmalloc requires allocating
    multiple pages that are contiguous, which might not be possible if
    there's heavy memory fragmentation. Therefore fallback to vmalloc if
    we fail to allocate with kmalloc. Also start with a smaller buffer size,
    since xattr values typically are smaller than a page.
    
    Reported-by: Chris Murphy <lists@colorremedies.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: Chris Mason <clm@fb.com>


-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC



  reply	other threads:[~2014-12-22 11:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-20  2:07 Can BTRFS handle XATTRs larger than 4K? Richard Sharpe
2014-12-20  8:38 ` Chris Murphy
2014-12-22 11:38   ` Chris Samuel [this message]
2014-12-22 11:41     ` Chris Samuel
2014-12-22 14:28 ` Austin S Hemmelgarn
2014-12-22 17:27   ` Richard Sharpe
2014-12-22 18:09     ` Austin S Hemmelgarn
2014-12-22 18:43       ` Chris Murphy
2014-12-22 19:56         ` Austin S Hemmelgarn
2014-12-22 20:06         ` Richard Sharpe
2014-12-22 20:44           ` Austin S Hemmelgarn
2014-12-22 20:50             ` Richard Sharpe
2014-12-22 22:52             ` Robert White
2014-12-22 22:55               ` Richard Sharpe
2014-12-23  0:08                 ` Robert White
2014-12-23  1:16                   ` Richard Sharpe
2014-12-23 12:37                   ` Austin S Hemmelgarn
2014-12-22 23:15               ` ronnie sahlberg
2014-12-22 23:55                 ` Robert White
2014-12-22 23:58                   ` Richard Sharpe
2014-12-23  0:11                     ` Robert White
2014-12-22 20:04       ` Richard Sharpe
2014-12-22 20:33         ` Austin S Hemmelgarn

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=3748928.v6JPJNQWc6@quad \
    --to=chris@csamuel.org \
    --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).