linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Dhaval Giani <dgiani@mozilla.com>
Cc: linux-kernel@vger.kernel.org, tytso@mit.edu, tglek@mozilla.com,
	vdjeric@mozilla.com, glandium@mozilla.com,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC/PATCH 0/2] ext4: Transparent Decompression Support
Date: Thu, 25 Jul 2013 14:05:45 -0400	[thread overview]
Message-ID: <20130725180545.GB15590@logfs.org> (raw)
In-Reply-To: <51F14136.30409@mozilla.com>

On Thu, 25 July 2013 11:16:06 -0400, Dhaval Giani wrote:
> >
> >If you want to follow some other approach where userspace has one
> >interface to write the compressed data to a file and some other
> >interface to read the file uncompressed, you are likely in a world of
> >pain.
> Why? If it is going to only be a few applications who know the file
> is compressed, and read it to get decompressed data, why would it be
> painful?

It would likely require an ABI extention.  Your immediate pain would
be to get past a wall of NAK when you propose the extention.  You have
to make a rather convincing case that the ABI extention cannot cause
VFS or filesystem maintainers future pain in some dark cornercase.

Just because the one application you care about only wants to use
compression on write-once files doesn't prevent the next person from
abusing the new ABI.  Such abuse should be strictly limited,
preferrably impossible.

I am not saying that I object.  Just warning you to brace yourself for
impact.

> What about introducing a new flag, O_COMPR which tells the
> kernel, btw, we want this file to be decompressed if it can be. It
> can fallback to O_RDONLY or something like that? That gets rid of
> the chattr ugliness.

How is that different from chattr ugliness, which also comes down to a
single flag? ;)

Jörn

--
/* Keep these two variables together */
int bar;

  parent reply	other threads:[~2013-07-25 18:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-24 21:03 [RFC/PATCH 0/2] ext4: Transparent Decompression Support Dhaval Giani
2013-07-24 23:36 ` Jörn Engel
2013-07-25 15:16   ` Dhaval Giani
2013-07-25 15:29     ` Phillip Lougher
2013-07-25 16:42     ` Taras Glek
2013-07-25 17:53       ` Jörn Engel
2013-07-25 19:27         ` Dhaval Giani
2013-07-25 18:15       ` Vyacheslav Dubeyko
2013-07-25 18:35         ` Dhaval Giani
2013-07-26  8:01           ` Vyacheslav Dubeyko
2013-07-26 13:20             ` Jörn Engel
2013-07-29 23:15               ` Mike Hommey
2013-08-04  0:33               ` Theodore Ts'o
2013-08-04  2:21                 ` Jörn Engel
2013-08-04 23:48                   ` Dave Chinner
2013-08-07  9:21                     ` Andreas Dilger
2013-08-07 15:52                       ` Jörn Engel
     [not found]         ` <51F16B9A.5020006@mozilla.com>
2013-07-26  7:47           ` Vyacheslav Dubeyko
2013-07-25 18:05     ` Jörn Engel [this message]
2013-07-25 20:09       ` Zach Brown
2013-07-25 18:46         ` Jörn Engel

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=20130725180545.GB15590@logfs.org \
    --to=joern@logfs.org \
    --cc=dgiani@mozilla.com \
    --cc=glandium@mozilla.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglek@mozilla.com \
    --cc=tytso@mit.edu \
    --cc=vdjeric@mozilla.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 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).