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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.