From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Joshua Hudson <joshudson@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] add support for larger files in minix filesystem
Date: Sat, 9 Jan 2016 21:37:20 +0000 [thread overview]
Message-ID: <20160109213720.52b2740e@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <CA+jjjYTsKKR2FjXV7f0rLHaN8iLndVd3OkV3m_WdYOM2jsOJAg@mail.gmail.com>
> I accessed the minix code at
> http://users.sosdg.org/~qiyong/mxr/source/minix/fs/mfs/read.c
> and they use unsigned for the block variables so the kernel would be
> fine with it; except for super.c truncates the cap at 2GB, so they
> simply won't be able to open large files.
The question is what users in general (notably Minix) do with that. As I
read it both Minix and ELKS will get mightily upset by files over 2GB
long. It would be bad if Linux allowed a user to corrupt their minixfs
images as seen by the normal users of Minix fs.
> Maybe we'd be happier if I limited this to a new superblock magic value;
> and their code won't even mount it.
Yep. That would be sensible. You might also want to pick a fixed
endianness and also decide the bit-endianness of the file system. Minixfs
proper made rather a mess of that.
If your physical media does not suffer from needing to keep blocks on the
same disk cylinder (ie rotating rust) then the V7 file system is even
smaller than the Minix one but also has the 2GB limit.
Alan
next prev parent reply other threads:[~2016-01-09 21:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-02 3:56 Joshua Hudson
2015-11-03 2:13 ` Joshua Hudson
2016-01-09 3:37 ` Al Viro
2016-01-09 18:45 ` Joshua Hudson
2016-01-09 21:37 ` One Thousand Gnomes [this message]
2016-01-09 23:11 ` Al Viro
2016-01-09 23:43 ` Joshua Hudson
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=20160109213720.52b2740e@lxorguk.ukuu.org.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=joshudson@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®