linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Vyacheslav Dubeyko <slava@dubeyko.com>
Cc: Dhaval Giani <dgiani@mozilla.com>, Taras Glek <tglek@mozilla.com>,
	linux-kernel@vger.kernel.org, tytso@mit.edu, 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: Fri, 26 Jul 2013 09:20:34 -0400	[thread overview]
Message-ID: <20130726132034.GB21977@logfs.org> (raw)
In-Reply-To: <1374825683.3671.35.camel@slavad-ubuntu>

On Fri, 26 July 2013 12:01:23 +0400, Vyacheslav Dubeyko wrote:
> 
> We are discussing not about good or bad idea. We need to elaborate a
> right solution. I think that suggested idea is not clear. Do you want to
> support compression in ext4? Or do you want to add some new compression
> feature (likewise file-oriented compression)? If we are talking about
> compression in ext4 then it needs to use e2compr patch set. Otherwise,
> if we are talking about file compression then it is not question of
> concrete filesystem. And we need to make implementation on VFS level. It
> is only architectural point of view.

I don't think the e2compr patches are strictly necessary.  They are a
good option, but not the only one.

One trick to simplify the problem is to make Dhaval's compressed files
strictly read-only.  It will require some dance to load the compressed
content, flip the switch, then uncompress data on the fly and disallow
writes.  Not the most pleasing of interfaces, but yet another option.

> Why do you try to implement likewise concept on kernel level? It looks
> like you try to move some user-space concept in kernel-space.

The kernel controls the page cache.  Once the page cache is filled
with uncompressed file content, you can do mmap, regular file io, etc.
Putting uncompression code into the kernel makes sense to me.  Whether
a solution different from e2compr makes sense is yet to be seen.

Whatever you do, it will require support from the on-disk format and
the userspace ABI.  Setting the compression bit on a file has the
clear advantage that it is an established interface and also supported
by other filesystems.  Introducing yet another interface requires a
fairly strong case to be made.  But who knows, maybe Dhaval can pull
it off.

Jörn

--
Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.
-- Bill Gates
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-07-26 14:52 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 [this message]
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
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=20130726132034.GB21977@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).