From: Chris Mason <clm@fb.com>
To: Hugo Mills <hugo@carfax.org.uk>, Martin <m_btrfs@ml1.co.uk>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS extended attributes mounted on a non-extended-attributes compiled kernel
Date: Wed, 11 Dec 2013 14:43:36 -0500 [thread overview]
Message-ID: <20131211194327.12817.49789@ret> (raw)
In-Reply-To: <20131211190104.GM9738@carfax.org.uk>
Quoting Hugo Mills (2013-12-11 14:01:04)
> On Wed, Dec 11, 2013 at 05:51:06PM +0000, Martin wrote:
> > What happens if...
> >
> > I have a btrfs that has utilised posix ACLs / extended attributes and I
> > then subsequently mount that onto a system that does not have the kernel
> > modules compiled for those features?
> >
> >
> > Crash and burn?
> >
> > Or are the extra filesystem features benignly ignored until remounted on
> > the original system with all the kernel modules?
>
> Thinking about it, it's probably going to be OK. btrfs itself
> doesn't have any way of turning off EA support, so you'll always have
> the EAs managed correctly. The ACL support (which is implemented
> through EAs, if I remember correctly) can be turned off, so the
> meaning of the ACL EAs will be ignored, but the EA content should
> still be there for when you move to an ACL-enabled system again. Note
> that this gives you a "convenient" way of bypassing POSIX ACLs, by
> switching to a kernel that doesn't enforce them.
>
> I've not actually tried this, so I'm willing to be proved wrong,
> but I'll be surprised if that's the case. :)
I do expect it to silently work. If you have directories that inherit
acls etc, you might not get fully consistent results if you try to
change anything on the non-xattr/acl kernel.
-chris
prev parent reply other threads:[~2013-12-11 19:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-11 17:51 BTRFS extended attributes mounted on a non-extended-attributes compiled kernel Martin
2013-12-11 19:01 ` Hugo Mills
2013-12-11 19:43 ` Chris Mason [this message]
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=20131211194327.12817.49789@ret \
--to=clm@fb.com \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=m_btrfs@ml1.co.uk \
/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).