From: Jeff Moyer <jmoyer@redhat.com>
To: Andrew Patterson <andrew.patterson@hp.com>
Cc: linux-scsi@vger.kernel.org,
James.Bottomley@HansenPartnership.com,
linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
axboe@kernel.dk, andmike@linux.vnet.ibm.com, mike.miller@hp.com,
genanr@emsphone.com
Subject: Re: [PATCH 5/6] Added flush_disk to factor out common buffer cache flushing code.
Date: Thu, 04 Sep 2008 09:13:16 -0400 [thread overview]
Message-ID: <x49d4jkm4ur.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <1220501780.6601.14.camel@grinch> (Andrew Patterson's message of "Thu, 04 Sep 2008 04:16:20 +0000")
Andrew Patterson <andrew.patterson@hp.com> writes:
> On Wed, 2008-09-03 at 14:19 -0400, Jeff Moyer wrote:
>> Andrew Patterson <andrew.patterson@hp.com> writes:
>>
>> > Added flush_disk to factor out common buffer cache flushing code.
>> >
>> > We need to be able to flush the buffer cache for for more than
>> > just when a disk is changed, so we factor out common cache flush code
>> > in check_disk_change() to an internal flush_disk() routine. This
>> > routine will then be used for both disk changes and disk resizes (in a
>> > later patch).
>> >
>> > Include the disk name in the text indicating that there are busy
>> > inodes on the device and increase the KERN severity of the message.
>> >
>> > Signed-off-by: Andrew Patterson <andrew.patterson@hp.com>
>> Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
>>
>> > +static void flush_disk(struct block_device *bdev)
>> > +{
>> > + if (__invalidate_device(bdev)) {
>> > + char name[BDEVNAME_SIZE] = "";
>> > +
>> > + if (bdev->bd_disk)
>> > + disk_name(bdev->bd_disk, 0, name);
>> > + printk(KERN_WARNING "VFS: busy inodes on changed media %s\n",
>> > + name);
>> > + }
>>
>> This message will scare folks growing their devices online. Can you
>> think of some better verbiage for this?
>
> This message is shared with the check_disk_change() routine. Yes, it is
> scary, but perhaps that is to the good. We have no guarantee how the
> user changed the underlying storage. For example, they might have
> shrunk the volume below the size of an underlying file-system and then
> grew it again before kicking off the resize detection (admittedly a
> degenerate case), in which case the warning is appropriate. Any
> suggestions on better wording?
I'm not sure how verbose we want to be with printk's; it's a dilemma.
Any verbiage suggesting that strictly growing the partition is safe
would be welcome, but I agree, that's tough to convey at this point.
I guess I'm okay with things as they stand, but I do think this will
generate customer calls. ;)
-Jeff
next prev parent reply other threads:[~2008-09-04 13:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-29 23:12 [PATCH 0/6] detect online disk resize Andrew Patterson
2008-08-29 23:13 ` [PATCH 1/6] Wrapper for lower-level revalidate_disk routines Andrew Patterson
2008-09-03 18:16 ` Jeff Moyer
2008-08-29 23:13 ` [PATCH 2/6] Adjust block device size after an online resize of a disk Andrew Patterson
2008-09-03 18:17 ` Jeff Moyer
2008-08-29 23:13 ` [PATCH 3/6] Check for device resize when rescanning partitions Andrew Patterson
2008-09-03 18:17 ` Jeff Moyer
2008-08-29 23:13 ` [PATCH 4/6] SCSI sd driver calls revalidate_disk wrapper Andrew Patterson
2008-09-03 18:17 ` Jeff Moyer
2008-08-29 23:13 ` [PATCH 5/6] Added flush_disk to factor out common buffer cache flushing code Andrew Patterson
2008-09-03 18:19 ` Jeff Moyer
2008-09-04 4:16 ` Andrew Patterson
2008-09-04 13:13 ` Jeff Moyer [this message]
2008-08-29 23:13 ` [PATCH 6/6] Call flush_disk() after detecting an online resize Andrew Patterson
2008-09-03 18:20 ` Jeff Moyer
2008-09-04 7:26 ` [PATCH 0/6] detect online disk resize Jens Axboe
2008-09-04 14:25 ` Andrew Patterson
2008-09-08 18:01 ` Jeff Moyer
2008-09-09 7:41 ` Pasi Kärkkäinen
2008-09-24 15:23 ` Vladislav Bolkhovitin
2008-09-04 20:27 Andrew Patterson
2008-09-04 20:27 ` [PATCH 5/6] Added flush_disk to factor out common buffer cache flushing code Andrew Patterson
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=x49d4jkm4ur.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=andmike@linux.vnet.ibm.com \
--cc=andrew.patterson@hp.com \
--cc=axboe@kernel.dk \
--cc=genanr@emsphone.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mike.miller@hp.com \
--cc=viro@zeniv.linux.org.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;
as well as URLs for NNTP newsgroup(s).