From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756479AbcAIVhb (ORCPT ); Sat, 9 Jan 2016 16:37:31 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:36170 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756402AbcAIVh3 (ORCPT ); Sat, 9 Jan 2016 16:37:29 -0500 Date: Sat, 9 Jan 2016 21:37:20 +0000 From: One Thousand Gnomes To: Joshua Hudson Cc: Al Viro , linux-kernel Subject: Re: [PATCH] add support for larger files in minix filesystem Message-ID: <20160109213720.52b2740e@lxorguk.ukuu.org.uk> In-Reply-To: References: <20160109033712.GA5955@ZenIV.linux.org.uk> Organization: Intel Corporation X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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