From: Jari Ruusu <jari.ruusu@pp.inet.fi>
To: Anton Altaparmakov <aia21@cam.ac.uk>
Cc: Andries.Brouwer@cwi.nl, torvalds@transmeta.com,
R.E.Wolff@BitWizard.nl, axboe@suse.de,
linux-kernel@vger.kernel.org
Subject: Re: loop device broken in 2.4.6-pre5
Date: Wed, 27 Jun 2001 14:54:21 +0300 [thread overview]
Message-ID: <3B39C96D.8BCDB2D7@pp.inet.fi> (raw)
In-Reply-To: <UTC200106261041.MAA454888.aeb@vlet.cwi.nl> <5.1.0.14.2.20010626200527.03c285c0@pop.cus.cam.ac.uk>
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>
next prev parent reply other threads:[~2001-06-27 11:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-26 10:41 loop device broken in 2.4.6-pre5 Andries.Brouwer
2001-06-26 10:52 ` Rogier Wolff
2001-06-26 17:59 ` Jari Ruusu
2001-06-26 19:14 ` Anton Altaparmakov
2001-06-27 11:54 ` Jari Ruusu [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-06-26 13:31 Andries.Brouwer
2001-06-21 22:58 Andries.Brouwer
2001-06-22 13:59 ` Jari Ruusu
2001-06-26 8:18 ` Jari Ruusu
2001-06-25 16:31 ` Rogier Wolff
2001-06-21 16:43 Jari Ruusu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B39C96D.8BCDB2D7@pp.inet.fi \
--to=jari.ruusu@pp.inet.fi \
--cc=Andries.Brouwer@cwi.nl \
--cc=R.E.Wolff@BitWizard.nl \
--cc=aia21@cam.ac.uk \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox