Opened 9 years ago

Closed 6 years ago

#913 closed bug (cannotreproduce)

umount problem while using two usb disk.

Reported by: luca.necchi@… Owned by:
Priority: normal Milestone:
Component: fon-base-firmware Version: (Gari)
Severity: unknown
Cc: Hardware: 2.0n (FON2300)


Hi. First of all, thx for this great product and for your work.

I've noticed that mountd does not automatically unmount a usb disk (sdb1) whether another usb disk (sda1) is in use. The condition is easy to reproduce... in my case I have a swap file on disk sda1. I have verified that there is no open file on the disk I hope to see unmounted (sdb1) through lsof command.

as soon as I issue a swapoff /tmp/run/mountd/sda1/extra-swap both the disk get correctly unmounted (proving that sdb1 had no open files)

I can, indeed, unmount the disk (sdb1) through the "umount" command from ssh command line, but mountd does not react properly and keep thinking the disk is there, bringing fon into some instability (Dashboard-Filebrowser web page hangs forever and sdb1 disk is not re-mounted once reconnected) that can be solved only by a reboot

this is really annoying because it becomes virtually impossible to umount a "data" disk while having a "system" disk (with swap, and various other packages installed) operational

Maybe mountd (that I could not figure out how to use) have some command line options (or setup) to do so

Many many thx in advance.

Attachments (2)

mounted_at_bootstrap.logread (9.5 KB) - added by luca.necchi@… 9 years ago.
swap_on_off.logread (15.8 KB) - added by anonymous 9 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 9 years ago by matthijs

  • Status changed from new to infoneeded

AFAIK, mountd should just unmount partitions when they are unused, so it shouldn't matter if one of them is still in use. So this is probably a bug in mountd or perhaps the kernel. A quick glance through the mountd source doesn't show up anything, I'll have to look closer.

In fact, for me this problem does not occur (When I keep one partition "open" by cd'ing into it, another partition, on another disk, is unmounted. I haven't tried actually mounting a swap file on a partition. Could you check if the issue still occurs for you when you just cd to the first disc, instead of mounting the swap file?

Could you attach the output of the "logread" command here, once after being idle for a while, and once after you unmounted the swap partition and the partition got unmounted?

comment:2 Changed 9 years ago by luca.necchi@…


I've been experimenting a little with logread (thx for pointing me there) It has been pretty difficult to confine the issue...

apparently this device, and only this one (It's a IPOD 4th generation, the ones with real HDD, vfat formatted) suffers the issue, but only if mounted at boot time. maybe this specific device keeps triggering some event on the usb channel (having, actually, an OS on board) in the "mounted_at_bootstrap.logread" You'll see that, If the device is connected at boot time (alone), it won't be never unmounted. It gets continuously mounted and umounted due to some "kernel is requesting a mount"

in the swap_on_off.logread you can see the behavior I was referring to in my original bug report (and the attempt to umount swap, that don't help... since sdb get unmounted while sda don't)

Some info: sdb1 is the system disk sda2 is the data disk (apple ipod) swap umount took place at Fri Sep 10 13:49:23 (as you can see from the following command line dump) root@Fonera:~# cat /proc/swaps

Filename Type Size Used Priority /tmp/run/mountd/sdb1/extra-swap file 65528 0 -1

root@Fonera:~# date; swapoff /tmp/run/mountd/sdb1/extra-swap ; cat /proc/swaps

Fri Sep 10 13:49:23 UTC 2010 Filename Type Size Used Priority

root@Fonera:~# lsof |grep sd root@Fonera:~#

If I attach the disk while fonera is already initialized, all the behaviors are proper

Frankly speaking, I don't consider this issue relevant any more. I'm happy enough if I can solve this issue by using an ext3 formatted disk as data disk

Changed 9 years ago by luca.necchi@…

Changed 9 years ago by anonymous

comment:3 Changed 6 years ago by matthijs

  • Resolution set to cannotreproduce
  • Status changed from infoneeded to closed

As part of the upcoming firmware release, we're reviewing old open tickets to see if they are still relevant, which is why you get this response now.

Given that this seems very device-specific and the reporter did not consider this issue relevant anymore, I'm closing this ticket.

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.