On Tue, Feb 05, 2019 at 06:09:39PM +0100, Stanislav Brabec wrote:
> Dne 05. 02. 19 v 10:00 Karel Zak napsal(a):
> > On Mon, Feb 04, 2019 at 05:38:56PM +0100, Stanislav Brabec wrote:
> >>> If we will keep the fstype lists in the code than we can use it as
> >>> the first attempt, if the name is not in the list than use your
> >>> heuristic.
> >>
> >> It makes sense.
> >
> > Note that source path may be a relative path without any '/'. It's
> > very unusual, but possible.
>
> I am aware of the fact that the driver can provide anything. Do we have any examples, where kernel or FUSE driver provides relative source path?
This is mount(2) syscall feature; for example I have "simple_mount",
just main() with mount(2) call:
# cd /dev
# simple_mount sdc /mnt/test ext4 1
# grep sdc /proc/self/mountinfo
530 94 8:32 / /mnt/test ro,relatime shared:275 - ext4 sdc ro,stripe=512
^^^
> I am just working on a list of all pseudo file systems available in
> the basic openSUSE repositories. Currently I have ~20 FUSE file
> systems to inspect.
>
> We also may have two lists: One list of pseudo file systems, second
> list of obscure pseudo file systems (that don't use relative paths).
> If the source does not start with "/" and file system is not in one
> of these lists, mount will return error. I can imagine that we can
> move this list from code to /etc/libmount/pseudofs.d/.
Some filesystems classification is already in /proc/filesystems. The
problem is that the list is incomplete (contains already loaded
filesystems only).
Maybe we need a generic filesystems classification rather than pseudo-filesystems
specific list. We also keep in the code table to convert magic numbers
to FS name (see mnt_statfs_get_fstype()).
What about /etc/libmount/fs.d/ for arbitrary filesystems and in the files
keep all the hints:
<name> <type> <magic>
for example:
autofs nodev 0x0187
cifs netfs 0xff534d42
The another possibility is not call mnt_resolve_path() on mount
output. The problem is that we need mnt_fs_is_pseudofs() on another
places like fstrim.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
