lkml.org 
[lkml]   [2001]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: loop device broken in 2.4.6-pre5
At 18:59 26/06/2001, Jari Ruusu wrote:
>Andries.Brouwer@cwi.nl wrote:
> > From jari.ruusu@pp.inet.fi 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


--
"Nothing succeeds like success." - Alexandre Dumas
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:55    [W:0.057 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site