linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Christoph Hellwig <hch@infradead.org>
Cc: Andreas Dilger <adilger@dilger.ca>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	"1o5g4r8o@gmail.com" <1o5g4r8o@gmail.com>,
	"738758@bugs.debian.org" <738758@bugs.debian.org>
Subject: Re: [PATCH] ext4: kill i_version support for Hurd-castrated file systems
Date: Thu, 20 Mar 2014 10:44:56 -0400	[thread overview]
Message-ID: <20140320144456.GA20618@thunk.org> (raw)
In-Reply-To: <20140320081048.GA21164@infradead.org>

On Thu, Mar 20, 2014 at 01:10:48AM -0700, Christoph Hellwig wrote:
> On Wed, Mar 19, 2014 at 11:27:57PM -0600, Andreas Dilger wrote:
> > Probably worthwhile to make those !EXT4_OS_HURD checks likely()?

Yes, and I was planning on optimizing the checks a bit more, but it
makes sense to do that in a separate patch, since this is not the only
place where we are making EXT4_OS_HURD checks.

> 
> Does it make sense to support the format at all given that it's unlikely
> to get any testing?

There are some crazy people still trying to make the Hurd a viable
file system.  There's even a Debian port for it.  :-) The problem is
that some of the folks who are still trying to make the Hurd real want
to use ext2 as an interchange format between Linux and Hurd, and
presumably that's how they ran across this particular bug.

While I think Hurd is a joke, and it's laughable that the primary file
system for the Hurd doesn't support journalling, or extents, delayed
allocation, or extended attributes[1], and it's hard for them get feature
parity because of the GPL v3 vs v2 compatibility problem, I don't mind
making minimal efforts to provide legacy support to the GNU Hurd.

[1] http://savannah.gnu.org/patch/?5126 (Patches available for the last
      seven years, not yet integrated)

In the long run, the right answer is that the Hurd should use an
extended attribute to store the translator information.  Indeed, this
has been discussed seven years ago[2].  But unfortunately, the
development temp for Hurd is a wee bit slower than for the Linux
kernel.  :-)

[2] http://savannah.gnu.org/task/?5503

					- Ted

  reply	other threads:[~2014-03-20 14:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20140212185534.GA4005@phenomenon>
2014-03-19 20:20 ` Bug#738758: linux-image-3.12-1-amd64: ext4 can't properly handle ext2 filesystems created for GNU/Hurd Gabriele Giacone
2014-03-20  4:34   ` [PATCH] ext4: kill i_version support for Hurd-castrated file systems Theodore Ts'o
2014-03-20  5:27     ` Andreas Dilger
2014-03-20  8:10       ` Christoph Hellwig
2014-03-20 14:44         ` tytso [this message]
2014-03-20 17:30           ` Bug#738758: " Ben Hutchings
2014-03-21 14:39             ` tytso
2014-03-21 16:48               ` [PATCH] ext4: optimize Hurd tests when reading/writing inodes Theodore Ts'o
2014-03-21 17:11                 ` Bug#738758: " Samuel Thibault

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=20140320144456.GA20618@thunk.org \
    --to=tytso@mit.edu \
    --cc=1o5g4r8o@gmail.com \
    --cc=738758@bugs.debian.org \
    --cc=adilger@dilger.ca \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    /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).