linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Tejun Heo <tj@kernel.org>
Cc: Jan Kara <jack@suse.cz>, Hui Wang <hui.wang@canonical.com>,
	viro@zeniv.linux.org.uk, kay.sievers@vrfy.org,
	jaxboe@fusionio.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] vfs: try to unblock evpoll if mounted filesystem is RDONLY
Date: Thu, 25 Jul 2013 19:27:23 +0200	[thread overview]
Message-ID: <20130725172723.GA18011@quack.suse.cz> (raw)
In-Reply-To: <20130725153335.GG26107@mtj.dyndns.org>

On Thu 25-07-13 11:33:35, Tejun Heo wrote:
> Hello, Jan.
> 
> On Thu, Jul 25, 2013 at 12:03:58PM +0200, Jan Kara wrote:
> > When we are asked to RW mount in case filesystem cannot really do RW, we
> > return -EROFS instead of silently falling back to RO mount. Userspace
> > mount(8) command will try again with MS_RDONLY set so things should still
> > work OK and the problems with eject button would be solved. I'll try to
> > code that up.
> 
> Hmmm.... while it is neat, it is very visible to userland and I'm a
> bit concerned that we might break some obscure tool which isn't using
> the standard mount.  Not sure about udf but for iso9660, which is
> vastly more common anyway, just always setting MS_RDONLY seems like
> the better solution.
  Well, the trick is that if the media is not writeable, mount without
MS_RDONLY will fail even currently (tried that in practice, also see the
check in blkdev_get_by_path()). So such tool should handle that case even
currently. The only somewhat realistic case I'm aware of is if someone uses
UDF on e.g. USB stick, it is created so that Linux doesn't support writing
to it, and then some tool would be mounting it directly via syscall and would
not handle the read-only media case right. But I don't find this likely so
I think it would be worth trying out this approach before we try playing
tricks with dropping write access... Hmm?

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2013-07-25 17:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-08  2:02 [PATCH] vfs: try to unblock evpoll if mounted filesystem is RDONLY Hui Wang
2013-07-23 15:45 ` Tejun Heo
2013-07-23 21:48   ` Jan Kara
2013-07-24 10:08     ` Hui Wang
2013-07-24 18:39       ` Jan Kara
2013-07-25  3:24         ` Hui Wang
2013-07-25 10:03           ` Jan Kara
2013-07-25 10:46             ` Hui Wang
2013-07-25 15:33             ` Tejun Heo
2013-07-25 17:27               ` Jan Kara [this message]
2013-07-25 17:30                 ` Tejun Heo

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=20130725172723.GA18011@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=hui.wang@canonical.com \
    --cc=jaxboe@fusionio.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tj@kernel.org \
    --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).