On Mon, Feb 12, 2018 at 10:06:57AM -0600, Eric Sandeen wrote: > > > On 2/12/18 9:45 AM, Lukas Czerner wrote: > > On Mon, Feb 12, 2018 at 02:14:19PM +0300, Artem Blagodarenko wrote: > >> From: Alexey Lyashkov <alexey.lyashkov@xxxxxxxxx> > >> > >> Sometimes during system deployment customers are faced with system > >> formating problem for given inodes/bytes rate. User need to recalucate > >> this rate and start formating again. > >> > >> This patch adds code that limit inodes count instead of error return, > >> to use all inodes in the filesystem. > > > > Hi, > > > > in this case then you do not have byte-per-inode ratio you've > > specified. So why to specify it in the first place ? > > > > Maybe I am missing something but I would think that if you specify -i > > then you know what you want and if it's not possible then I would not > > expect the mke2fs to just succeed regardless. I guess it's confusing. > > I agree that fixing up incorrect/impossible format specifications and > continuing is not preferable; it really makes the behavior matrix complex > when some incorrect options are fixed on the fly, while others fail. > > And worse, this creates a new "default" behavior which comes into play > only when specific incorrect mkfs options are explicitly provided. > > When an admin stops using mkfs defaults and starts manually specifying > geometry, the onus is on /them/ to specify options which are valid. > > > Also the man page says: > > > > "This value generally shouldn't be smaller than the blocksize of the > > filesystem, since in that case more inodes would be made than can ever > > be used." > > > > But in your case you're using "-i 1024" on what I assume is a 4k bs file > > system ? > > Right, can you offer a concrete example of the commandline you're trying > to fix? > > If it's "-i 1024" on a 4k filesystem, that's simply broken and /should/ > be rejected. If the error message is not clear, perhaps that's the best > place to focus these efforts. I think that inline data actually changes that ? However if that's the case then we need to change the documentation. But it still does not mean we want to "autocorrect" spcified values. -Lukas > > Thanks, > -Eric
