All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs-progs: add supported attr flags to btrfs(5)
Date: Fri, 27 Jun 2014 17:30:18 +0200	[thread overview]
Message-ID: <20140627153017.GF1553@suse.cz> (raw)
In-Reply-To: <53AD860A.8090804@redhat.com>

On Fri, Jun 27, 2014 at 09:56:10AM -0500, Eric Sandeen wrote:
> > * and 'X' does not mean "no compression" and never has, although I'd
> >   like to see a chattr bit for that because we have the corresponding
> >   inode bit
> 
> Ok, then I'm not sure what it does mean.  Supposedly these flags are supported;
> via check_flags(), called by setflags(), which I was basing these on:
> 
>         if (flags & ~(FS_IMMUTABLE_FL | FS_APPEND_FL | \
>                       FS_NOATIME_FL | FS_NODUMP_FL | \
>                       FS_SYNC_FL | FS_DIRSYNC_FL | \
>                       FS_NOCOMP_FL | FS_COMPR_FL |
>                       FS_NOCOW_FL))
> 
> and the kernel header says that's:
> 
> #define FS_NOCOMP_FL                    0x00000400 /* Don't compress */

Passing this bit directly via ioctl works as expected, but to my
knowledge there is no chattr letter allocated for it.

> chattr(1) says: "compression raw access (X)," and also "The ’X’ attribute
> is used by the experimental compression patches to indicate that a raw
> contents of a compressed file  can  be  accessed  directly.  It currently 
> may not be set or reset using chattr(1), although it can be displayed by lsattr(1)."
> 
> Hum, ok, so we are starting to go off the rails here, aren't we ;)

Yeah. And there's no support for accessing raw compressed data.

> e2fsprogs has this flag translation:
>          { EXT2_NOCOMPR_FL, "X", "Compression_Raw_Access" },
> for:
> #define EXT2_NOCOMPR_FL                 0x00000400 /* Access raw compressed data */
> 
> and btrfs_ioctl_setflags claims to handle it:
> 
>         if (flags & FS_NOCOMP_FL) {
>                 ip->flags &= ~BTRFS_INODE_COMPRESS;
>                 ip->flags |= BTRFS_INODE_NOCOMPRESS;
> 		...
> 
> so hopefully you can understand my confusion? ;)

Oh I do now, but it's ext2 fault :)

> The comment says:
> 
>          * The COMPRESS flag can only be changed by users, while the NOCOMPRESS
>          * flag may be changed automatically if compression code won't make
>          * things smaller.
> 
> (but doesn't says "may *only* be...")

And thats IMO right (at least I expect it work like that), the user may
set or drop the NOCOMPRESS flag. The comment says that it may appear
without user interaction.

> But OTOH, chattr won't ever even *pass* "X" to the fs, will it.
> 
> So I guess I'm lost.  It looks like there's code to handle an incoming
> "X" but I don't think chattr will send it.
> 
> Do we ever get an outbound "X" for an opportunistically not-compressed file?
> If so, maybe that still needs to be specified.

AFAICS 'X' is not listed among the standard chattr options and chattr.c
in e2fsprogs has no support for that.

There is

lib/e2p/pf.c:   { EXT2_NOCOMPR_FL, "X", "Compression_Raw_Access" },

but this is used only locally by print_flags.

I hope this answers your questions, 'X' has no meaning for btrfs now.

  reply	other threads:[~2014-06-27 15:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26 20:38 [PATCH] btrfs-progs: add supported attr flags to btrfs(5) Eric Sandeen
2014-06-27 13:42 ` David Sterba
2014-06-27 14:56   ` Eric Sandeen
2014-06-27 15:30     ` David Sterba [this message]
2014-06-27 15:36       ` Eric Sandeen
2014-06-27 16:10         ` David Sterba
2014-06-27 16:38           ` Eric Sandeen
2014-07-01 17:43             ` David Sterba
2014-07-02 11:15               ` David Sterba

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=20140627153017.GF1553@suse.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.