On Fri, Jun 26, 2020 at 03:36:02PM +0200, Sven Hoexter wrote:
On Fri, Jun 26, 2020 at 09:08:27AM -0400, Michael Stone wrote:
Now that exfat is available as a kernel module, it would be nice if
the
/sbin/mount.exfat link were removed to make it easier for a user to
choose
either the exfat kernel module or the fuse module at runtime.
Currently the
link masks the kernel module so that exfat-fuse is always used,
without the
link the kernel module would be used by default but mounting with -t
exfat-fuse
would use the fuse implementation.
Yes, I already started to think about what the future of the fuse exfat
stack
could look like. From my personal point of view we could drop it.
OTOH for some people an independent implementation might still provide
some
value. So maybe your proposal to just move it a bit out of the way is a
good
first step.
Yeah, I personally am really happy to switch to a better performing
implementation because my only use for exfat is pulling large amounts of
data off fast removeable storage and the fuse implementation has been a
bottleneck. That said, the fuse implementation has a much longer track
record and some people may be happy to stick with it for a while longer,
especially if their use case involves writing data or if performance
isn't an issue. In my mind the ideal situation would be to not break any
existing systems, while still defaulting to the kernel implementation if
it's available, and letting users disable the kernel implementation if
that's their preference.
On Fri, Jun 26, 2020 at 03:39:29PM +0200, Sven Hoexter wrote:
On Fri, Jun 26, 2020 at 09:22:18AM -0400, Michael Stone wrote:
Alternatively, perhaps replacing the mount.exfat link with something like
the following would be a better option, to transparently support kernels
with and without the native module:
#!/bin/sh
if grep -qF exfat /proc/filesystems || modinfo exfat > /dev/null 2>&1 ; then
mount -i $*
else
mount.exfat-fuse $*
fi
Well as soon as a recent kernel enters testing I believe it
would just cause confusion. Main audience to profit would be
people using testing/unstable with an old or custom kernel
and none Linux ports from my point of view.
Would that help someone in the end?
Or custom kernels, or backports. Definitely not mainstream, but
something along these lines should keep exfat mounts working
transparently regardless of kernel support.
Here's a slight variation:
#!/bin/sh
set -e
modprobe -b exfat > /dev/null 2>&1 || true
if grep -qF exfat /proc/filesystems; then
mount -i $*
else
mount.exfat-fuse $*
fi
This one would let someone blacklist the kernel module and everything
would continue working with the fuse implementation. OTOH, it is linux
specific (maybe just leaving the symlink as-is would work on non-linux?)
and if you don't want to bother maintaining something like this I
wouldn't argue about that decision.
