Bug 194526 - sysutils/fusefs-ntfs: ntfs-3g with libublio lost files
Summary: sysutils/fusefs-ntfs: ntfs-3g with libublio lost files
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: Normal Affects Some People
Assignee: Kubilay Kocak
URL:
Keywords:
Depends on: 206978
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-22 05:04 UTC by Sergey Kuzmichov
Modified: 2019-11-28 10:18 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Kuzmichov 2014-10-22 05:04:37 UTC
If I create a new empty file on NTFS partition and then I reboot system with command "reboot" in Terminal, then after reboot new file is not exist on NTFS partition.
If I disable libublio support in NTFS-3G, then file is NOT losted.
If I manually unmount partition before reboot - file is NOT losted.

skuz@Desktop-PC:~ % pkg info | egrep "ublio|ntfs"
fusefs-ntfs-2014.2.15_2        Mount NTFS partitions (read/write) and disk images
libublio-20070103              User space caching library

skuz@Desktop-PC:~ % freebsd-version -ku
10.1-RC2-p1
10.1-RC2-p1
Comment 1 John Marino freebsd_committer 2014-11-01 12:05:36 UTC
I am making an educated guess that the OP is talking about the unmaintained sysutils/fusefs-ntfs port, and changing the title accordingly.

Moving this PR to "open" since there's no one to assign it to and there's no patch to apply.
Comment 2 Jason Unovitch freebsd_committer 2016-06-05 22:53:42 UTC
Add new maintainer to CC.
Comment 3 Walter Schwarzenfeld freebsd_triage 2018-01-13 20:09:20 UTC
fusefs-ntfs has now 2017.3.23. I think this is overcome by events and could be closed.
Comment 4 Sergey Kuzmichov 2019-01-07 05:28:59 UTC
(In reply to w.schwarzenfeld from comment #3)

No. Bug is still exists. I think that libublio do not flush a cache to disk with some interval (for example? every 1 seconds). This is brings to situation when small piece of last data always storage in memory.
Comment 5 Alan Somers freebsd_committer 2019-04-03 15:21:58 UTC
Is this a duplicate of 206978 ?  Could you try the patch from that bug?
Comment 6 Sergey Kuzmichov 2019-04-04 03:37:48 UTC
(In reply to Alan Somers from comment #5)
What a patch did you mean? In the 206978 bug I see only patch for disable libublio, but in my first post I already talked that disabled libublio solves issue with losted files. But without libublio the performance is very poor.
Comment 7 Alan Somers freebsd_committer 2019-04-04 03:41:50 UTC
koobs says that he wants to disable libuio due to "a number of bugs that have been reported for it".  If libuio is going to go away, then this bug will go away too.
Comment 8 Alan Somers freebsd_committer 2019-08-08 20:53:30 UTC
In the latest head, fusefs now has sane cacheing builtin.  Can we eliminate libublio now?
Comment 9 Alexey Dokuchaev freebsd_committer 2019-11-28 10:18:39 UTC
(In reply to Sergey Kuzmichov from comment #6)
> I already talked that disabled libublio solves issue with lost files.
Another good reason to kill this option.  Basically, because of it being enabled by default, we (FreeBSD) ship very broken package.  This upsets our users and gives us bad image.

> But without libublio the performance is very poor.
Earlier this year, FUSE subsystem had seen a major update: the protocol
level was raised from 7.8 to 7.23, it fixed many bugs, and added many new features, have a look:

  https://lists.freebsd.org/pipermail/freebsd-current/2019-August/073980.html

Sergey, could you reconduct your tests and see if performance issue persists?