linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Vyacheslav Dubeyko <slava@dubeyko.com>,
	Dhaval Giani <dgiani@mozilla.com>, Taras Glek <tglek@mozilla.com>,
	linux-kernel@vger.kernel.org, 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: Sat, 3 Aug 2013 22:21:14 -0400	[thread overview]
Message-ID: <20130804022114.GA24655@logfs.org> (raw)
In-Reply-To: <20130804003316.GA19781@thunk.org>

On Sat, 3 August 2013 20:33:16 -0400, Theodore Ts'o wrote:
> 
> P.P.S.  At least in theory, nothing of what I've described here has to
> be ext4 specific.  We could implement this in the VFS layer, at which
> point not only ext4 would benefit, but also btrfs, xfs, f2fs, etc.

Except for an inode bit that needs to be stored in the filesystem,
agreed.  The ugliness I see is in detecting how to treat the
filesystem at hand.

Filesystems with mandatory compression (jffs2, ubifs,...):
- Just write the file, nothing to do.
Filesystems with optional compression (logfs, ext2compr,...):
- You may or may not want to chattr between file creation and writing
  the payload.
Filesystems without compression (ext[234], xfs,...):
- Just write the file, nothing can be done.
- Alternatively fall back to a userspace version.
Filesystems with optional uncompression (what is being proposed):
- Write the file in compressed form, close, chattr.

I would like to see the compression side done in the kernel as well.
Then we can chattr right after creat() and, if that fails, either
proceed anyway or go to a userspace fallback.  All decisions can be
made early on and we don't have to share the format with lots of
userspace.

Sure, we still have to share the format with fsck and similar
filesystem tools.  But not with installers.

Jörn

--
Man darf nicht das, was uns unwahrscheinlich und unnatürlich erscheint,
mit dem verwechseln, was absolut unmöglich ist.
-- Carl Friedrich Gauß

  reply	other threads:[~2013-08-04  2:21 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 [this message]
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
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=20130804022114.GA24655@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=slava@dubeyko.com \
    --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).