Re: [PATCH] add support for larger files in minix filesystem
From: Joshua Hudson
Date: Sat Jan 09 2016 - 18:44:26 EST
On 1/9/16, One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx> wrote:
>> I accessed the minix code at
>> 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.
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
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
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
I will certainly consider using another superblock magic value.