Re: loop device broken in 2.4.6-pre5

Re: loop device broken in 2.4.6-pre5

[Andries.Brouwer]

    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.)

Andries

Re: loop device broken in 2.4.6-pre5

[Rogier Wolff]

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.)

I thought the change was a "quick hack" that would make stuff work
(page cache?) near the end of the file. That would mean that this kind
of "quick hack" won't work. 

But if it does anyway, then indeed 512 would be a more appropriate
choice.

I thought I had to convince people, so I chose a sitation that I hoped
people would understand to be likely/possible, to prevent reactions:
"No filesystem will use the last odd numbered 512bytes of a
partition".

				Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: loop device broken in 2.4.6-pre5

[Jari Ruusu]

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.

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>

Re: loop device broken in 2.4.6-pre5

[Anton Altaparmakov]

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/

Re: loop device broken in 2.4.6-pre5

[Jari Ruusu]

Anton Altaparmakov wrote:
> 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!

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

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>

Re: loop device broken in 2.4.6-pre5

[Andries.Brouwer]

Rogier Wolff writes:

>> But why 1024?
>> (Or make the set blocksize ioctl also work on loop devices.)

> I thought the change was a "quick hack" that would make stuff work
> (page cache?) near the end of the file. That would mean that this kind
> of "quick hack" won't work. 

I am not sure I can parse your sentence.
But:

# blockdev --getbsz /dev/loop1
0
# dd if=/dev/zero of=tenbl bs=1024 count=10
10+0 records in
10+0 records out
# losetup /dev/loop1 tenbl
# blockdev --getbsz /dev/loop1
4096
# dd if=/dev/zero of=/dev/loop1 bs=1024 count=10
dd: writing `/dev/loop1': No space left on device
9+0 records in
8+0 records out
# blockdev --setbsz 2048 /dev/loop1
# blockdev --getbsz /dev/loop1
2048
# dd if=/dev/zero of=/dev/loop1 bs=1024 count=10
10+0 records in
10+0 records out
#

Andries

Re: loop device broken in 2.4.6-pre5

[Andries.Brouwer]

    From: Jari Ruusu <jari.ruusu@pp.inet.fi>

    File backed loop device on 4k block size ext2 filesystem:

    # dd if=/dev/zero of=file1 bs=1024 count=10
    10+0 records in
    10+0 records out
    # losetup /dev/loop0 file1
    # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc
    dd: /dev/loop0: No space left on device
    9+0 records in
    8+0 records out
    # tune2fs -l /dev/hda1 2>&1| grep "Block size"
    Block size:               4096
    # uname -a
    Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown

    Stock 2.4.5 and 2.4.5-ac15 don't have this problem.

I am not sure there is an error here.

The default block size of a loop device is that of the underlying device.
There was a kernel bug that was recently fixed, where the block size
of a file backed loop device could be essentially random.
So, earlier you happened to get blocksize 1024, and you had room for
10 blocks of size 1024.
Now you have blocksize 4096, and you have room for 2 blocks of size 4096.
There are no fractional blocks at the end of a block device.

Andries

Re: loop device broken in 2.4.6-pre5

[Jari Ruusu]

Andries.Brouwer@cwi.nl wrote:
>     From: Jari Ruusu <jari.ruusu@pp.inet.fi>
> 
>     File backed loop device on 4k block size ext2 filesystem:
> 
>     # dd if=/dev/zero of=file1 bs=1024 count=10
>     10+0 records in
>     10+0 records out
>     # losetup /dev/loop0 file1
>     # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc
>     dd: /dev/loop0: No space left on device
>     9+0 records in
>     8+0 records out
>     # tune2fs -l /dev/hda1 2>&1| grep "Block size"
>     Block size:               4096
>     # uname -a
>     Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown
> 
>     Stock 2.4.5 and 2.4.5-ac15 don't have this problem.
> 
> I am not sure there is an error here.
> 
> The default block size of a loop device is that of the underlying device.
> There was a kernel bug that was recently fixed, where the block size
> of a file backed loop device could be essentially random.
> So, earlier you happened to get blocksize 1024, and you had room for
> 10 blocks of size 1024.
> Now you have blocksize 4096, and you have room for 2 blocks of size 4096.
> There are no fractional blocks at the end of a block device.

Why can't we keep the default at 1024 regardless of what the block size of
underlying device is. There are some situations where all of loop device
must be accessed before it is mounted (at which point the block size is set
to desired value).

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>

Re: loop device broken in 2.4.6-pre5

[Jari Ruusu]

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);

Jari Ruusu wrote:
> Andries.Brouwer@cwi.nl wrote:
> >     From: Jari Ruusu <jari.ruusu@pp.inet.fi>
> >
> >     File backed loop device on 4k block size ext2 filesystem:
> >
> >     # dd if=/dev/zero of=file1 bs=1024 count=10
> >     10+0 records in
> >     10+0 records out
> >     # losetup /dev/loop0 file1
> >     # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc
> >     dd: /dev/loop0: No space left on device
> >     9+0 records in
> >     8+0 records out
> >     # tune2fs -l /dev/hda1 2>&1| grep "Block size"
> >     Block size:               4096
> >     # uname -a
> >     Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown
> >
> >     Stock 2.4.5 and 2.4.5-ac15 don't have this problem.
> >
> > I am not sure there is an error here.
> >
> > The default block size of a loop device is that of the underlying device.
> > There was a kernel bug that was recently fixed, where the block size
> > of a file backed loop device could be essentially random.
> > So, earlier you happened to get blocksize 1024, and you had room for
> > 10 blocks of size 1024.
> > Now you have blocksize 4096, and you have room for 2 blocks of size 4096.
> > There are no fractional blocks at the end of a block device.
> 
> Why can't we keep the default at 1024 regardless of what the block size of
> underlying device is. There are some situations where all of loop device
> must be accessed before it is mounted (at which point the block size is set
> to desired value).

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>

Re: loop device broken in 2.4.6-pre5

[Rogier Wolff]

Andries.Brouwer@cwi.nl wrote:
>     From: Jari Ruusu <jari.ruusu@pp.inet.fi>
> 
>     File backed loop device on 4k block size ext2 filesystem:
> 
>     # dd if=/dev/zero of=file1 bs=1024 count=10
>     10+0 records in
>     10+0 records out
>     # losetup /dev/loop0 file1
>     # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc
>     dd: /dev/loop0: No space left on device
>     9+0 records in
>     8+0 records out
>     # tune2fs -l /dev/hda1 2>&1| grep "Block size"
>     Block size:               4096
>     # uname -a
>     Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown
> 
>     Stock 2.4.5 and 2.4.5-ac15 don't have this problem.
> 
> I am not sure there is an error here.

How about:

dd if=/dev/hda1 of=disk.img bs=1k 
mount disk.img /mnt/d1 -o loop


If the filesystem on hda1 happens to use the last 2k of the partition,
and the partition size is 2k mod 4k, then I get a non-working disk.img
if I don't pad the disk.img file with another 2k. And then I might
trip up the "how big is this partition" code in the fs-driver....

				Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

loop device broken in 2.4.6-pre5

[Jari Ruusu]

File backed loop device on 4k block size ext2 filesystem:

debian:/root # dd if=/dev/zero of=file1 bs=1024 count=10
10+0 records in
10+0 records out
debian:/root # losetup /dev/loop0 file1
debian:/root # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc
dd: /dev/loop0: No space left on device                   <=====ERROR=====
9+0 records in
8+0 records out
debian:/root # tune2fs -l /dev/hda1 2>&1| grep "Block size"
Block size:               4096
debian:/root # uname -a
Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown

Stock 2.4.5 and 2.4.5-ac15 don't have this problem.

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>