From: Nathan Scott <nathans@sgi.com>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] blkdev_open/bd_claim vs BLKBSZSET
Date: Tue, 24 Feb 2004 10:53:39 +1100 [thread overview]
Message-ID: <20040223235339.GC773@frodo> (raw)
In-Reply-To: <20040223232803.GD31035@parcelfarce.linux.theplanet.co.uk>
On Mon, Feb 23, 2004 at 11:28:04PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Tue, Feb 24, 2004 at 10:17:05AM +1100, Nathan Scott wrote:
> > Hi there,
> >
> > I was modifying mkfs.xfs to use O_EXCL for 2.6, and hit a snag.
> > It seems that once I've opened a block dev with O_EXCL I can no
> > longer issue the BLKBSZSET ioctl to it. (Is that the expected
> > behavior? If so, ignore...)
>
> > And mkfs gets EBUSY back from the ioctl. Using the patch
> > below, the ioctl succeeds cos the original filp bdev owner
> > from open now matches with the owner in the ioctl call. I
> > suspect that would be the correct behavior, but perhaps I'm
> > overlooking some good reason for it being this way?
>
> <shrug> it can be done that way, but I really wonder why the hell does
> mkfs.xfs bother with BLKBSZSET in the first place?
Thats taking me back a few years - IIRC this was originally added
because mkfs.xfs zeroes out the last N KB of the device before it
goes on to creating the XFS filesystem. Waaay back (~3 years now?)
there was a problem when someone had, say, a 4K block size ext2 fs
on the device - mount/unmount of that left the device block size at
4K in the kernel, when mkfs.xfs then came along it would not be able
to zero the last small-amount-less-than-4K of the device (on devices
where the size was not 4K aligned only - heh, that was a fun wrinkle)
and mkfs would see write-past-end-of-device errors.
No idea if that can still happen in 2.6, I imagine it can in 2.4
where we originally saw the problem.
> FWIW, that ioctl is practically never the right thing to do these days.
> I'm not saying that we shouldn't apply the patch - it looks sane - but
> it looks like mkfs.xfs is doing something bogus.
At least for some older kernel versions this was needed - possibly
still is, I'm not sure.
cheers.
--
Nathan
next prev parent reply other threads:[~2004-02-23 23:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-23 23:17 [PATCH] blkdev_open/bd_claim vs BLKBSZSET Nathan Scott
2004-02-23 23:28 ` viro
2004-02-23 23:53 ` Nathan Scott [this message]
2004-02-24 0:54 ` viro
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=20040223235339.GC773@frodo \
--to=nathans@sgi.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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