From: Goffredo Baroncelli <kreijack@inwind.it>
To: Anand Jain <anand.jain@oracle.com>
Cc: Goffredo Baroncelli <kreijack@libero.it>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
David Sterba <dsterba@suse.cz>,
Zygo Blaxell <zblaxell@furryterror.org>
Subject: Re: [RFC][PATCH v2] mount.btrfs helper
Date: Thu, 04 Dec 2014 18:58:27 +0100 [thread overview]
Message-ID: <5480A0C3.5050708@inwind.it> (raw)
In-Reply-To: <547FC24A.9000107@oracle.com>
On 12/04/2014 03:09 AM, Anand Jain wrote:
>
>
> On 01/12/2014 01:43, Goffredo Baroncelli wrote:
>> Hi all,
>>
>> this patch provides a "mount.btrfs" helper for the mount command. A
>> btrfs filesystem could span several disks. This helper scans all
>> the partitions to discover all the disks required to mount a
>> filesystem. So it would not necessary any-more to "scan" the
>> partitions to mount a filesystem.
>>
>> mount.btrfs passes in the option parameters the devices required to
>> mount a filesystem. Supposing that a filesystem is composed by
>> several disks (/dev/sd[cdef]), when the user runs "mount /dev/sdd
>> /mnt", mount.btrfs is called and it executes the the mount(2)
>> syscall as below:
>>
>> mount("/dev/sdd", "/mnt", "btrfs", 0, "device=/dev/sdc,device=/dev/sde,device=/de/vsdf").
>
>
> in linux its bit messy that there are different name/paths to the
> same device, its the way it is. So btrfs-progs normalizes these paths
> to "a" thing and provide it to the kernel during btrfs dev scan.
> since device path normalization is done at the user space level not
> in the kernel, the device paths sent using mount option would miss
> this part.
Good point. I have to normalize the path. I put this in my todo list.
What I am not sure is the case when the user passes the devices via
device=.... options explicitly.
In this case I prefer to leave these as are... The (super user) know what
he is doing....
>
> -Anand
>
>
[...]
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2014-12-04 17:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-30 17:43 [RFC][PATCH v2] mount.btrfs helper Goffredo Baroncelli
2014-11-30 22:11 ` Dimitri John Ledkov
2014-11-30 22:31 ` cwillu
2014-11-30 22:57 ` Dimitri John Ledkov
2014-11-30 23:27 ` cwillu
2014-12-05 15:32 ` Chris Mason
2014-12-05 16:01 ` Dimitri John Ledkov
2014-12-05 16:41 ` David Sterba
2014-12-05 18:15 ` Goffredo Baroncelli
2014-12-05 18:43 ` Chris Mason
2014-12-05 19:51 ` Goffredo Baroncelli
2014-12-09 12:16 ` David Sterba
2014-12-09 10:55 ` David Sterba
2014-12-09 10:35 ` David Sterba
2014-12-04 2:09 ` Anand Jain
2014-12-04 17:58 ` Goffredo Baroncelli [this message]
2014-12-05 3:16 ` Anand Jain
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=5480A0C3.5050708@inwind.it \
--to=kreijack@inwind.it \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=kreijack@libero.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=zblaxell@furryterror.org \
/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