Bug 264983 - sysutils/fusefs-ntfs: Support device offset to mount
Summary: sysutils/fusefs-ntfs: Support device offset to mount
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL: https://github.com/tuxera/ntfs-3g/iss...
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-01 17:31 UTC by Konstantin Germanov
Modified: 2023-02-26 08:52 UTC (History)
5 users (show)

See Also:
grahamperrin: maintainer-feedback-
jbeich: maintainer-feedback? (danfe)


Attachments
add dev_offset (16.68 KB, application/mbox)
2022-07-01 17:31 UTC, Konstantin Germanov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Germanov 2022-07-01 17:31:07 UTC
Created attachment 235027 [details]
add dev_offset

Usually NTFS volume located on device at some offset.
We can use losetup/mdconfig for map device from offset to another device and mount this device.
But there are some problems:

It is new resourse, which has limited && can be leak
Method of mount is not portabled
Need copy data twice: for loop device and fuse
If we pass argument for device offset we can avoid such problems.

There is patch to implement this.
Comment 1 Graham Perrin freebsd_committer freebsd_triage 2022-07-09 10:11:12 UTC
Cross-reference (in the read-only mirror): <https://github.com/freebsd/freebsd-ports/pull/128>.
Comment 2 Gleb Popov freebsd_committer freebsd_triage 2023-01-25 20:05:21 UTC
Why submit this patch to FreeBSD instead of fusefs-ntfs upstream?
Comment 3 Jan Beich freebsd_committer freebsd_triage 2023-02-25 10:06:20 UTC
Let's ask for review someone who updated this port in the past.

(In reply to Gleb Popov from comment #2)
The URL field of this bug links to an upstream issue with an unmerged pull request.
Comment 4 Alexey Dokuchaev freebsd_committer freebsd_triage 2023-02-25 12:37:38 UTC
(In reply to Konstantin Germanov from comment #0)
> Need copy data twice: for loop device and fuse
Have you measured the actual overhead of this extra layer under real workload?

Admittedly, I tend to agree with upstream that this patch (or rather, eight patches) is dubious and does not solve something otherwise unsolvable.  Keeping this size of patchset in the port means we'd have to resolve potential conflicts upon updates and provide support/bugfixes for this custom code, that's something we'd want to avoid.  If it would be merged upstream but e.g. disabled by default, we could enable it in the port, but keeping big chunks of code in the port itself is bad practice.
Comment 5 Eugene Grosbein freebsd_committer freebsd_triage 2023-02-25 19:26:56 UTC
I'd like to add that we already have perfectly working geom_map(4) that allows us to define /dev/map/NAME over existing GEOM using offsets and kenv(1) utility, then use such /dev/map/NAME for ntfs or anything else.
Comment 6 Alexey Dokuchaev freebsd_committer freebsd_triage 2023-02-26 08:52:27 UTC
Closing per comment #5, geom_map(4) does exactly what you need with zero overhead.