FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Sun Nov 29, 2020 00:44



Post new topic Reply to topic  [ 13 posts ] 
NTFS-3g behaves very unstable on my FreeBSD 7.1 
Author Message

Joined: Fri Apr 17, 2009 08:50
Posts: 4
Post NTFS-3g behaves very unstable on my FreeBSD 7.1
Hi everybody

I've installed ntfs-3g (fusefs-ntfs) on a newly setup FreeBSD 7.1 machine, but it keeps crashing in irregular intervals for no apparent reason. Check out my /var/log/messages:

Apr 16 21:36:54 blackbox ntfs-3g[67147]: Unmounting /dev/da1s1 (Archive)
Apr 16 21:36:57 blackbox kernel: GEOM_LABEL: Label for provider da1s1 is ntfs/Archive.
Apr 16 21:37:10 blackbox kernel: GEOM_LABEL: Label ntfs/Archive removed.
Apr 16 21:37:37 blackbox ntfs-3g[5241]: Version 1.2531 external FUSE 27
Apr 16 21:37:37 blackbox ntfs-3g[5241]: Mounted /dev/da1s1 (Read-Write, label "Archive", NTFS 3.1)
Apr 16 21:37:37 blackbox ntfs-3g[5241]: Cmdline options: blkdev,blksize=4096,locale=de_CH.UTF-8
Apr 16 21:37:37 blackbox ntfs-3g[5241]: Mount options: blkdev,silent,allow_other,nonempty,relatime,fsname=/dev/da1s1
Apr 17 03:01:06 blackbox kernel: pid 5241 (ntfs-3g), uid 0: exited on signal 6 (core dumped)
Apr 17 03:01:07 blackbox kernel: GEOM_LABEL: Label for provider da1s1 is ntfs/Archive.

..Yesteday evening I manually mounted my NTFS USB drive again and then, at 3am it just died. There was noone logged in and my deamons didn't read/write to it either.

I guess if this was a common problem much more people would be complaining about. On the other hand, I really didn't try to do anything extraordinary. Does anybody have any ideas what my cause this instability?

TIA
dave


Fri Apr 17, 2009 09:06
Profile

Joined: Fri Apr 17, 2009 08:50
Posts: 4
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
Just to clarify: the machine itself doesn't crarsh, but fuse core dumps as shown in the log.


Fri Apr 17, 2009 10:42
Profile
Tuxera CTO

Joined: Tue Nov 21, 2006 23:15
Posts: 1648
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
The coredump backtrace could be useful

Please look for the 'core' file (root or start directory). Once you have it run gdb with the path to ntfs-3g and to the core file. Example:

o gdb /usr/local/bin/ntfs-3g /core

Then at the gdb prompt, run:

o (gdb) bt

Also, do you have any ntfs-3g error messages in any of the log files under /var/log?


Fri Apr 17, 2009 10:50
Profile

Joined: Fri Apr 17, 2009 08:50
Posts: 4
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
Hi szaka

/var/log/messages is as good as it gets. I've looked around, but didn't find any more useful log entries.. As for your other suggestion, here's the gdb backtrace:

gdb /usr/local/bin/ntfs-3g /ntfs-3g.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `ntfs-3g'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/local/lib/libfuse.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libfuse.so.2
Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libiconv.so.3
Reading symbols from /usr/local/lib/libntfs-3g.so.31...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libntfs-3g.so.31
Reading symbols from /usr/local/lib/libublio.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libublio.so.1
Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x282afa07 in kill () from /lib/libc.so.7
[New Thread 0x28301100 (LWP 100096)]
(gdb) bt
#0 0x282afa07 in kill () from /lib/libc.so.7
#1 0x281cd147 in raise () from /lib/libthr.so.3
#2 0x282ae57a in abort () from /lib/libc.so.7
#3 0x282959e6 in __assert () from /lib/libc.so.7
#4 0x28089a7c in forget_node () from /usr/local/lib/libfuse.so.2
#5 0x28089fe0 in fuse_lib_forget () from /usr/local/lib/libfuse.so.2
#6 0x2808f728 in do_forget () from /usr/local/lib/libfuse.so.2
#7 0x2808fbb1 in fuse_ll_process () from /usr/local/lib/libfuse.so.2
#8 0x280924d6 in fuse_session_process () from /usr/local/lib/libfuse.so.2
#9 0x2808e780 in fuse_session_loop () from /usr/local/lib/libfuse.so.2
#10 0x2808ade8 in fuse_loop () from /usr/local/lib/libfuse.so.2
#11 0x00000003 in ?? ()
#12 0xbfbfe7f8 in ?? ()
#13 0x0804c3c6 in ?? ()
#14 0x283e2020 in ?? ()
#15 0x0804dac0 in ?? ()
#16 0x000008b5 in ?? ()
#17 0x00000008 in ?? ()
#18 0x00000000 in ?? ()
#19 0x0804ddb3 in ?? ()
#20 0x28317040 in ?? ()
#21 0x0804dd93 in ?? ()
#22 0x283050a0 in ?? ()
#23 0x00000003 in ?? ()
#24 0x00000001 in ?? ()
#25 0x00000000 in ?? ()
#26 0x2804f53c in ?? () from /libexec/ld-elf.so.1
#27 0x00000ef0 in ?? ()
#28 0x00000000 in ?? ()
#29 0x283050b4 in ?? ()
#30 0x283e2020 in ?? ()
#31 0x00000000 in ?? ()
#32 0x00000000 in ?? ()
#33 0x283050a0 in ?? ()
#34 0x28317040 in ?? ()
#35 0x0804dd93 in ?? ()
#36 0x0100ff00 in ?? ()
#37 0x00000052 in ?? ()
#38 0x000121a0 in ?? ()
#39 0x00000000 in ?? ()
#40 0x00000005 in ?? ()
#41 0x00000052 in ?? ()
#42 0x49e7bbf8 in ?? ()
#43 0x00000000 in ?? ()
#44 0x49e7bbf8 in ?? ()
#45 0x00000000 in ?? ()
#46 0x49e7bbf8 in ?? ()
#47 0x00000000 in ?? ()
#48 0x00000000 in ?? ()
#49 0x00000000 in ?? ()
#50 0x00000000 in ?? ()
#51 0x00000000 in ?? ()
#52 0x00001000 in ?? ()
#53 0x00000000 in ?? ()
#54 0x00000000 in ?? ()
#55 0x00000000 in ?? ()
#56 0xffffffff in ?? ()
#57 0xffffffff in ?? ()
#58 0x00000000 in ?? ()
#59 0x00000000 in ?? ()
#60 0x28055c76 in dlopen () from /libexec/ld-elf.so.1
Previous frame inner to this frame (corrupt stack?)
(gdb)

Guess with debuging symbols it would be more helpful (would I have to recomplile for that?)...


Fri Apr 17, 2009 12:00
Profile
Tuxera CTO

Joined: Tue Nov 21, 2006 23:15
Posts: 1648
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
This was useful, thank you.

The crash is in FUSE. It could be a kernel bug. I forwarded it to the FreeBSD/FUSE guru.


Fri Apr 17, 2009 13:57
Profile

Joined: Fri Apr 17, 2009 08:50
Posts: 4
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
Ok, I will leave it at that. Thanks for the quick response!


Fri Apr 17, 2009 14:50
Profile

Joined: Thu Jan 14, 2010 10:54
Posts: 4
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
I have the same problem here.
Since I disabled the coredump, I did not get one.
Mine also crashed with signal 6.
The matter bothers me is that after I remounted the partition, all the new files I copied in since last mount had lost...
This seriously annoyed me, and I think that if this happens several times, I'll switch to other formats...
I've enabled coredump, and I'm waiting for another crash....


Thu Jan 14, 2010 15:54
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
Hi,

Quote:
The matter bothers me is that after I remounted the partition, all the new files I copied in since last mount had lost...

In such situation the partition may be inconsistent. You should do a chkdsk.
Quote:
I've enabled coredump, and I'm waiting for another crash....

And more information is needed to be of any help.

Regards

Jean-Pierre


Thu Jan 14, 2010 20:02
Profile

Joined: Thu Jan 14, 2010 10:54
Posts: 4
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
Oh, and finally it crashed again, and it is somewhere repeatable....
I tried to extract one file from an rar archive on an NTFS disk to the same directory. After the extraction finished, I viewed that directory and ... ntfs-3g crashed...
The first core dump I got does not contain symbol information. So I built a new version of fuse-libs with symbol information, and the problem appeared again with similar steps...
Here's the backtrace:

(gdb) where
#0 0x282daea7 in kill () from /lib/libc.so.7
#1 0x281e5337 in raise () from /lib/libthr.so.3
#2 0x282d99da in abort () from /lib/libc.so.7
#3 0x28097a1d in get_node (f=0x28453240, nodeid=0) at fuse.c:268
#4 0x280981d3 in get_path_name (f=0x28453240, nodeid=0, name=0x0) at fuse.c:455
#5 0x280982c0 in get_path (f=0x28453240, nodeid=0) at fuse.c:478
#6 0x2809e109 in fuse_lib_release (req=0x28427240, ino=0, fi=0xbfbfe970) at fuse.c:2618
#7 0x280a1c41 in do_release (req=0x28427240, nodeid=0, inarg=0x285c1028) at fuse_lowlevel.c:678
#8 0x280a3055 in fuse_ll_process (data=0x28420380, buf=0x285c1000 "@", len=64, ch=0x2841f2c0) at fuse_lowlevel.c:1182
#9 0x280a49bb in fuse_session_process (se=0x2841f2e0, buf=0x285c1000 "@", len=64, ch=0x2841f2c0) at fuse_session.c:90
#10 0x2809fb29 in fuse_session_loop (se=0x2841f2e0) at fuse_loop.c:33
#11 0x2809e995 in fuse_loop (f=0x28453240) at fuse.c:2843
#12 0x0804c499 in ?? ()
#13 0x28453240 in ?? ()
#14 0x18000000 in ?? ()
#15 0x2842806c in ?? ()
....
#115 <signal handler called>
(gdb) l
263 {
264 struct node *node = get_node_nocheck(f, nodeid);
265 if (!node) {
266 fprintf(stderr, "fuse internal error: node %llu not found\n",
267 (unsigned long long) nodeid);
268 abort();
269 }
270 return node;
271 }
272
(gdb) p nodeid
$1 = 0
(gdb) p f
$2 = (struct fuse *) 0x28453240
(gdb) p *f
$3 = {se = 0x2841f2e0, name_table = 0x284d1000, name_table_size = 14057, id_table = 0x284df000, id_table_size = 14057, ctr = 40, generation = 0, hidectr = 1, lock = 0x28427200, tree_lock = 0x284060a0,
conf = {uid = 0, gid = 0, umask = 0, entry_timeout = 1, negative_timeout = 0, attr_timeout = 0, ac_attr_timeout = 0, ac_attr_timeout_set = 0, debug = 0, hard_remove = 0, use_ino = 1, readdir_ino = 1,
set_mode = 0, set_uid = 0, set_gid = 0, direct_io = 0, kernel_cache = 1, auto_cache = 0, intr = 0, intr_signal = 30, help = 0, modules = 0x0}, intr_installed = 0, fs = 0x28453300}
(gdb) p f->fs
$4 = (struct fuse_fs *) 0x28453300
(gdb) p *f->fs
$5 = {op = {getattr = 0x804b520 <ntfs_log_handler_syslog+8756>, readlink = 0x804ab50 <ntfs_log_handler_syslog+6244>, getdir = 0, mknod = 0x804a160 <ntfs_log_handler_syslog+3700>,
mkdir = 0x804a350 <ntfs_log_handler_syslog+4196>, unlink = 0x804b170 <ntfs_log_handler_syslog+7812>, rmdir = 0x804a320 <ntfs_log_handler_syslog+4148>, symlink = 0x804a390 <ntfs_log_handler_syslog+4260>,
rename = 0x804b270 <ntfs_log_handler_syslog+8068>, link = 0x804afe0 <ntfs_log_handler_syslog+7412>, chmod = 0x804a430 <ntfs_log_handler_syslog+4420>, chown = 0x804a3e0 <ntfs_log_handler_syslog+4340>,
truncate = 0x804aed0 <ntfs_log_handler_syslog+7140>, utime = 0x804a270 <ntfs_log_handler_syslog+3972>, open = 0x804add0 <ntfs_log_handler_syslog+6884>, read = 0x804a8a0 <ntfs_log_handler_syslog+5556>,
write = 0x804a670 <ntfs_log_handler_syslog+4996>, statfs = 0x80497b0 <ntfs_log_handler_syslog+1220>, flush = 0, release = 0, fsync = 0, setxattr = 0, getxattr = 0, listxattr = 0, removexattr = 0,
opendir = 0, readdir = 0x804a180 <ntfs_log_handler_syslog+3732>, releasedir = 0, fsyncdir = 0, init = 0, destroy = 0x804d040 <ntfs_log_handler_syslog+15700>, access = 0,
create = 0x804a140 <ntfs_log_handler_syslog+3668>, ftruncate = 0, fgetattr = 0, lock = 0, utimens = 0, bmap = 0}, m = 0x0, user_data = 0x0, compat = 0}
(gdb) l get_node_nocheck
246 }
247 pthread_mutex_unlock(&fuse_context_lock);
248 }
249
250 static struct node *get_node_nocheck(struct fuse *f, fuse_ino_t nodeid)
251 {
252 size_t hash = nodeid % f->id_table_size;
253 struct node *node;
254
255 for (node = f->id_table[hash]; node != NULL; node = node->id_next)
(gdb) l
256 if (node->nodeid == nodeid)
257 return node;
258
259 return NULL;
260 }
261
262 static struct node *get_node(struct fuse *f, fuse_ino_t nodeid)
263 {
264 struct node *node = get_node_nocheck(f, nodeid);
265 if (!node) {
(gdb) p f->id_table[0]
$6 = (struct node *) 0x0
(gdb) p f->id_table[1]
$7 = (struct node *) 0x28428290
(gdb) p f->id_table[2]
$8 = (struct node *) 0x284282e0
(gdb) p *f->id_table[1]
$9 = {name_next = 0x0, id_next = 0x0, nodeid = 1, generation = 0, refctr = 18, parent = 0x0, name = 0x2842c102 "/", nlookup = 1, open_count = 0, is_hidden = 0, stat_updated = {tv_sec = 0, tv_nsec = 0},
mtime = {tv_sec = 0, tv_nsec = 0}, size = 0, cache_valid = 0, locks = 0x0}
(gdb)

I'm willing to provide more information, and I will keep the core file.


Tue Feb 02, 2010 13:49
Profile

Joined: Thu Jan 14, 2010 10:54
Posts: 4
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
more information:
(gdb) frame 7
#7 0x280a1c41 in do_release (req=0x28427240, nodeid=0, inarg=0x285c1028) at fuse_lowlevel.c:678
678 req->f->op.release(req, nodeid, &fi);
(gdb) p *req
$15 = {f = 0x28420380, unique = 2, ctr = 1, lock = 0x28427280, ctx = {uid = 1001, gid = 0, pid = 1709}, ch = 0x2841f2c0, interrupted = 0, u = {i = {unique = 0}, ni = {func = 0, data = 0x0}},
next = 0x2842049c, prev = 0x2842049c}
I found pid 1709 is gam_server, and it is still running after the crash...


Tue Feb 02, 2010 14:08
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
Hi,

Quote:
Oh, and finally it crashed again,

Bad news.
Quote:
and it is somewhere repeatable....

So there is hope. But so far, I only have questions...

What versions of ntfs-3g and fuse are you using ?
Quote:
#3 0x28097a1d in get_node (f=0x28453240, nodeid=0) at fuse.c:268
#4 0x280981d3 in get_path_name (f=0x28453240, nodeid=0, name=0x0) at fuse.c:455
#5 0x280982c0 in get_path (f=0x28453240, nodeid=0) at fuse.c:478
#6 0x2809e109 in fuse_lib_release (req=0x28427240, ino=0, fi=0xbfbfe970) at fuse.c:2618
#7 0x280a1c41 in do_release (req=0x28427240, nodeid=0, inarg=0x285c1028) at fuse_lowlevel.c:678

Looks like fuse trying to release some inode data which it could not find. Memory corruption ?

Was there something special in the file you were extracting (conflicting name, special file type, ...) ? was it compressed file or encrypted (only in these two cases is release() meaningful to ntfs-3g) ?

What is the state of the file system after the crash ? Was the partially extracted file created ?
Quote:
I found pid 1709 is gam_server

What is that ? a process started by unrar or some independent process which would have interfered with the same data despite locks ? Does fuse crash when gam_server is not activated when you start unrar ?

There is nothing in your backtrace which mentions ntfs-3g. This sounds more like a bug in fuse. Can you post this to the fuse list (fuse-devel@lists.sourceforge.net), you are more likely to get a useful answer from them.

Regards

Jean-Pierre


Tue Feb 02, 2010 16:43
Profile

Joined: Thu Jan 14, 2010 10:54
Posts: 4
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
jpa wrote:
Hi,

Quote:
Oh, and finally it crashed again,

Bad news.
Quote:
and it is somewhere repeatable....

So there is hope. But so far, I only have questions...

What versions of ntfs-3g and fuse are you using ?

fusefs-ntfs-2009.4.4 (this is ntfs-3g's name in freebsd ports)
fusefs-libs-2.7.4
Quote:
Quote:
#3 0x28097a1d in get_node (f=0x28453240, nodeid=0) at fuse.c:268
#4 0x280981d3 in get_path_name (f=0x28453240, nodeid=0, name=0x0) at fuse.c:455
#5 0x280982c0 in get_path (f=0x28453240, nodeid=0) at fuse.c:478
#6 0x2809e109 in fuse_lib_release (req=0x28427240, ino=0, fi=0xbfbfe970) at fuse.c:2618
#7 0x280a1c41 in do_release (req=0x28427240, nodeid=0, inarg=0x285c1028) at fuse_lowlevel.c:678

Looks like fuse trying to release some inode data which it could not find. Memory corruption ?

Was there something special in the file you were extracting (conflicting name, special file type, ...) ? was it compressed file or encrypted (only in these two cases is release() meaningful to ntfs-3g) ?

No, the rar file and the result file are all normal files. I never enabled compression or encryption on this volume.
Quote:

What is the state of the file system after the crash ? Was the partially extracted file created ?

No, the file is lost. And when it crashes, the files created after this mount before the crash are always lost.
So it seems like that ntfs-3g does not sync some of its changes to the disk regularly... This is the most annoying, since the crash would lead to the lost of many files.... They occupy space, but I can't see them after I mount the volume later...
Quote:
Quote:
I found pid 1709 is gam_server

What is that ? a process started by unrar or some independent process which would have interfered with the same data despite locks ? Does fuse crash when gam_server is not activated when you start unrar ?

This comes from the port gamin, which is a file and directory monitoring system. It sends notifications to programs when files or directories changes. Maybe this program causes the problem...
Quote:

There is nothing in your backtrace which mentions ntfs-3g. This sounds more like a bug in fuse. Can you post this to the fuse list (fuse-devel@lists.sourceforge.net), you are more likely to get a useful answer from them.

Regards

Jean-Pierre

Ok, I'll try that..

Thanks for the quick reply!


Wed Feb 03, 2010 12:05
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: NTFS-3g behaves very unstable on my FreeBSD 7.1
Hi,

Quote:
No, the rar file and the result file are all normal files. I never enabled compression or encryption on this volume.

And they were not supported in ntfs-2009.4.4, there were no release() in that version of ntfs-3g.
Quote:
So it seems like that ntfs-3g does not sync some of its changes to the disk regularly... This is the most annoying, since the crash would lead to the lost of many files.... They occupy space, but I can't see them after I mount the volume later...

ntfs-3g syncs immediately after any change... but this does not mean the data reaches the storage when there is a software crash.
Quote:
This comes from the port gamin, which is a file and directory monitoring system. It sends notifications to programs when files or directories changes. Maybe this program causes the problem...

This means it hooks through some special way into the OS....

I would suggest upgrading to a newer version of fuse.

Regards

Jean-Pierre


Wed Feb 03, 2010 12:49
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.