Re: loop device broken in 2.4.6-pre5

[Jari Ruusu]

Anton Altaparmakov wrote:
> At 18:59 26/06/2001, Jari Ruusu wrote:
> >[e-mail] wrote:
> > >     From [e-mail] Tue Jun 26 10:20:51 2001
> > >
> > >     This patch fixes the problem. Please consider applying.
> > >
> > >     --- linux-2.4.6-pre5/drivers/block/loop.c    Sat Jun 23 07:52:39 2001
> > >     +++ linux/drivers/block/loop.c    Tue Jun 26 09:21:47 2001
> > >     @@ -653,7 +653,7 @@
> > >          bs = 0;
> > >          if (blksize_size[MAJOR(lo_device)])
> > >              bs = blksize_size[MAJOR(lo_device)][MINOR(lo_device)];
> > >     -    if (!bs)
> > >     +    if (!bs || S_ISREG(inode->i_mode))
> > >              bs = BLOCK_SIZE;
> > >
> > >          set_blocksize(dev, bs);
> > >
> > > But why 1024? Next week your neighbour comes and has a file-backed
> > > loop device with an odd number of 512-byte sectors.
> > > If you want a guarantee, then I suppose one should pick 512.
> > > (Or make the set blocksize ioctl also work on loop devices.)
> >
> >Because 1024 was the previous default. Keeping the same default that was
> >used before offers least surprises to users and tools.
> 
> But also makes it not work for odd number of sectors which is much worse IMHO.
> 
> Also it is far more surprising to find that the last sector is lost
> silently than to have a difference in behaviour, incorrect behaviour needs
> to be corrected not kept for backwards compatibility till the end of time.
> And the sooner that happens, the better. Both people and utilities will get
> used to it. Due to that 1024, mkntfs has to mark the disk dirty because it
> can never be sure just how many sectors there really are and hence can't be
> sure whether the backup boot sector was written to the correct place or not...
> 
> Also, the loop device is currently not consistent with the rest of the kernel:
> 
> * kernel physical block device: get_nr_sectors_sys_call returns the real
> number of 512 byte sectors
> * file mounted on loop device: sam sys_call returns the number of sectors & ~1.
> 
> This difference in behaviour causes a much bigger surprise than anything
> else if we are talking about surprises!

OK. My original complaint was that the default could be larger than 1024.
I am happy with 512.

Regards,
Jari Ruusu <[e-mail]>