Re: loop device broken in 2.4.6-pre5

[Anton Altaparmakov]

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!

Best regards,

Anton