Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1305155 > unrolled thread

Re: [PATCH] add support for larger files in minix filesystem

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] add support for larger files in minix filesystem Al Viro <viro@ZenIV.linux.org.uk> - 2016-01-09 04:40 +0100
    Re: [PATCH] add support for larger files in minix filesystem Joshua Hudson <joshudson@gmail.com> - 2016-01-09 19:50 +0100
      Re: [PATCH] add support for larger files in minix filesystem One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-09 22:40 +0100
        Re: [PATCH] add support for larger files in minix filesystem Al Viro <viro@ZenIV.linux.org.uk> - 2016-01-10 00:20 +0100
        Re: [PATCH] add support for larger files in minix filesystem Joshua Hudson <joshudson@gmail.com> - 2016-01-10 00:50 +0100

#1305155 — Re: [PATCH] add support for larger files in minix filesystem

On Sun, Nov 01, 2015 at 07:56:36PM -0800, Joshua Hudson wrote:
> From: Joshua Hudson <joshudson@gmail.com>
> 
> The Minix v3 filesystem and kernel driver have no actual dependency on files
> being less than 2GB in size; however the kernel does not allow creating a
> file of 2GB or larger on a Minix v3 filesystem. I was able to remove the pseudo-
> dependency easily by changing one line of code (filesystems need to tell VFS
> how big of files they allow).

Umm...  AFAICS, native Minix v3 fsck will throw a fit if it sees anything
between 2Gb and 4Gb and truncate the value.  Seeing that it's their
format _and_ silent changes like that (especially hidden by something like
"you need to binary-patch the field at this offset in superblock first")
are generally considered rude.

I'd suggest you to talk to Minix folks and convince them to raise that limit;
if it's merely a matter of unhappy fsck, it shouldn't be hard, but if their
minix/mfs/*.c code would get unhappy on files longer than 2Gb, it would be
harder and in that case we _really_ shouldn't run around creating such files
there.

Seriously, talk to Minix folks first.

[toc] | [next] | [standalone]

#1305345

> "you need to binary-patch the field at this offset in superblock first"
> are generally considered rude.

That is in fact the only reason why it's safe. I'm not using Minix at all
and don't care what its limit is. I'm using the Minix fs because it's the
only filesystem lightweight enough and fast enough for the embedded
hardware I am developing for (32K total RAM), and I want to be able
to mount the SD card in Linux.

The only alternative is developing a completely new filesystem, and
that's a lot more pain in the behind for everybody.

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.

Maybe we'd be happier if I limited this to a new superblock magic value;
and their code won't even mount it.

[toc] | [prev] | [next] | [standalone]

#1305363

> 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

[toc] | [prev] | [next] | [standalone]

#1305395

On Sat, Jan 09, 2016 at 09:37:20PM +0000, One Thousand Gnomes wrote:

> 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.

Keep in mind that v7 support comes along with sysvfs one, so the module
is quite likely bigger than in case of minixfs...

[toc] | [prev] | [next] | [standalone]

#1305396

On 1/9/16, One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
>> 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.

Already did. If I get a big-endian filesystem the embedded code rejects.
I also have to reject shift > 0 because then the buffers don't fit in RAM.

>
> 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
>

Doesn't -- SD card. And I can't meet my hard realtime requirement w/o
a free block bitmap so the only usable sysv variant is AFS and it's
readonly.

I was hoping to get a dirt-simple patch merged so I didn't have to
worry about getting the kernel to open the tape file the embedded
device collects its data; however it doesn't look like it's going to
happen. It would make sense to break the tape file up, but record
chunks
aren't powers of two in size at all so the break would fall in the
middle of a record.
It also places more strain on the embedded CPU than I'd like (no MUL
or DIV instruction).

(I call it a tape file because its internal structure looks like a
multi-track tape.)

I will certainly consider using another superblock magic value.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web