* Supporting human parsable journal_dev specifiers
@ 2014-07-10 14:28 Theodore Ts'o
2014-07-10 14:31 ` Christoph Hellwig
2014-07-15 11:52 ` Karel Zak
0 siblings, 2 replies; 3+ messages in thread
From: Theodore Ts'o @ 2014-07-10 14:28 UTC (permalink / raw)
To: util-linux
I have a user request that mount be able to interpret the device
specifier for the journal_dev mount option, so that instead of having
to type something like
mount -o journal_dev=0x0803 ....
they could unstead use: "journal_dev=/dev/sda3" or even
"journal_dev=LABEL=ext_journal". I assume the right way to do this is
a mount helper? Or is this something that you would be willing to
accept as a patch into util-linux?
If it is a mount helper, what's the best way to do things? Simply
parse through the mount options until finding the journal_dev one, and
then calling blkid or stat as necessary to interpret the argument, and
then re-exec mount with the modified mount option? Or is there some
gotchas involved with doing this?
Thanks,
- Ted
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Supporting human parsable journal_dev specifiers
2014-07-10 14:28 Supporting human parsable journal_dev specifiers Theodore Ts'o
@ 2014-07-10 14:31 ` Christoph Hellwig
2014-07-15 11:52 ` Karel Zak
1 sibling, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2014-07-10 14:31 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: util-linux
On Thu, Jul 10, 2014 at 10:28:24AM -0400, Theodore Ts'o wrote:
> I have a user request that mount be able to interpret the device
> specifier for the journal_dev mount option, so that instead of having
> to type something like
>
> mount -o journal_dev=0x0803 ....
>
> they could unstead use: "journal_dev=/dev/sda3" or even
> "journal_dev=LABEL=ext_journal". I assume the right way to do this is
> a mount helper? Or is this something that you would be willing to
> accept as a patch into util-linux?
At least for the device name the best is to implement it in the kernel,
take a look at what XFS is doing for the log device. The open by dev_t
functionality currently used by extN isn't something we like to see used
anyway.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Supporting human parsable journal_dev specifiers
2014-07-10 14:28 Supporting human parsable journal_dev specifiers Theodore Ts'o
2014-07-10 14:31 ` Christoph Hellwig
@ 2014-07-15 11:52 ` Karel Zak
1 sibling, 0 replies; 3+ messages in thread
From: Karel Zak @ 2014-07-15 11:52 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: util-linux
On Thu, Jul 10, 2014 at 10:28:24AM -0400, Theodore Ts'o wrote:
> I have a user request that mount be able to interpret the device
> specifier for the journal_dev mount option, so that instead of having
> to type something like
>
> mount -o journal_dev=0x0803 ....
>
> they could unstead use: "journal_dev=/dev/sda3" or even
> "journal_dev=LABEL=ext_journal". I assume the right way to do this is
> a mount helper? Or is this something that you would be willing to
> accept as a patch into util-linux?
I talked about it with Eric Sandeen year ago, and the decision was to
implement some generic FS independent solution based on variables in
mount options, something like
mount -o journal_dev=$(LABEL:<ext_journal_label>)
(or $LOGUUID for XFS log, etc).
It's not implemented yet, but I can try it if it's still necessary.
> If it is a mount helper, what's the best way to do things? Simply
Please, do not use mount helpers (/sbin/mount.<type>), it sucks in
many ways... it will be better to have a generic solution within
mount(8).
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-07-15 11:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-10 14:28 Supporting human parsable journal_dev specifiers Theodore Ts'o
2014-07-10 14:31 ` Christoph Hellwig
2014-07-15 11:52 ` Karel Zak
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox