LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Kernel (http://www.linuxquestions.org/questions/linux-kernel-70/)
-   -   umount slow and df reports wrong partition (http://www.linuxquestions.org/questions/linux-kernel-70/umount-slow-and-df-reports-wrong-partition-840837/)

aikempshall 10-27-2010 05:14 PM

umount slow and df reports wrong partition
 
Using slackware 13.1 and linux 2.6.33.4

For a long time I've used rsync to backup my documents directory to a usb stick without any issues. Since upgrading the umount command takes a very long time to umount the usb drive. This is what I do -


Code:

mount /dev/sdc1
rsync -av --delete --modify-window=4 -L /home/alex/Documents/ /mnt/backup/alex/Documents/
umount /dev/sdc1

As I've said the umount takes a very long time to do it's business. Bizarely the df command is showing something really strange -


before the mount

Code:

Filesystem            Size  Used Avail Use% Mounted on
/dev/root              37G  19G  17G  54% /
/dev/sdb2            101G  64G  33G  67% /home
tmpfs                1005M    0 1005M  0% /dev/shm


after the mount upto and including immediately before the umount. Note the addition of /dev/sdc1

Code:

Filesystem            Size  Used Avail Use% Mounted on
/dev/root              37G  19G  17G  54% /
/dev/sdb2            101G  64G  33G  67% /home
tmpfs                1005M    0 1005M  0% /dev/shm
/dev/sdc1            3.8G  2.9G  935M  76% /mnt/backup


Then immediately from when the umount is called to the time that the drive is unmounted. Note how the stats for /dev/sdc1 have changed -

Code:

Filesystem            Size  Used Avail Use% Mounted on
/dev/root              37G  19G  17G  54% /
/dev/sdb2            101G  64G  33G  67% /home
tmpfs                1005M    0 1005M  0% /dev/shm
/dev/sdc1              37G  19G  17G  54% /mnt/backup

Upto when the umount was called df reported the partition as -

/dev/sdc1 3.8G 2.9G 935M 76% /mnt/backup

whereas when it's being unmounted df reports

/dev/sdc1 37G 19G 17G 54% /mnt/backup

the Size, Used, Avail and Use% which df is reporting during the umount just so happens to be exactly the same numbers as df reports for /dev/root. So something's got confused somewhere.

Now if the system, on the umount, now sees a drive of 37G whereas it should see a drive of only 3.8G this could explain why it takes a long time to umount. However, there is minimal disk activity on /dev/root and a lot of activity on /dev/sdc1. Eventually it is the correct partition that is unmounted.


As this problem seems to be so bizarre and I've not managed to find a similar posting elsewhere I might elect to do a fresh install and see what happens.

Before I do that has anyone got any suggestions.

TobiSGD 10-28-2010 10:38 AM

I also recognized a change in my USB-device behaviour. If I copy a huge amount of data to a USB-stick, and the data is not to huge to go to the cache first, then the data is copied into the cache and the copy command returns. The real copy process is backgrounded to another thread. So if you immediatly unmount after copying the mount command waits until the data is copied.
I think this is the same thing that you have recognized on your system.

Please anybody, correct me if I am wrong here.


All times are GMT -5. The time now is 06:37 PM.