Delay in unmounting a USB pen drive

Delay in unmounting a USB pen drive

[Raj]

SuSE kernel 2.6.5:

My USB pen drive has a vfat FS. When i transfer some files & try to
unmount the drive ( umount /mnt ) , the command appears hung. CTRL+C also
does not work. Only later did i realise that it was actually taking a
longer time ( 10 - 15 sec )
to unmount.

My questions are:
- Why is it taking a long time to unmount ?
- Is it safe to remove the pen drive from it's slot when the umount is still in
  progress ?? ( I tried this the first time & maybe lucky me, the
files copied were fine )

TIA
-- 
######
raj
######

Re: Delay in unmounting a USB pen drive

[Anton Altaparmakov]

On Wed, 2004-11-24 at 14:55 +0530, Raj wrote:
> SuSE kernel 2.6.5:
> 
> My USB pen drive has a vfat FS. When i transfer some files & try to
> unmount the drive ( umount /mnt ) , the command appears hung. CTRL+C also
> does not work. Only later did i realise that it was actually taking a
> longer time ( 10 - 15 sec )
> to unmount.
> 
> My questions are:
> - Why is it taking a long time to unmount ?
> - Is it safe to remove the pen drive from it's slot when the umount is still in
>   progress ?? ( I tried this the first time & maybe lucky me, the
> files copied were fine )

You are mounting with async flag (or this is the default) which means
that all the unwritten data is synced when you do umount.  You can
verify this by typing "sync" waiting for that to complete and then the
umount should be immediate.

You can change this by using the "sync" option to mount which will cause
data to be written synchronously and the umount will be instantaneous.
Note that this will cause device write to be _much_ slower!

One thing is certain, do NOT unplug before the umount completes or you
will corrupt your fs on the stick for sure.

Best regards,

        Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: Delay in unmounting a USB pen drive

[Raj]

> You can change this by using the "sync" option to mount which will cause
> data to be written synchronously and the umount will be instantaneous.
> Note that this will cause device write to be _much_ slower!
> 

Tried 'mount -o sync /dev/sda /mnt' . After a 57MB file copy, i unmount.  Still
it takes a lot of time.

> One thing is certain, do NOT unplug before the umount completes or you
> will corrupt your fs on the stick for sure.

I shall remember this !. Thx very much. 

-- 
######
raj
######

Re: Delay in unmounting a USB pen drive

[Colin Leroy]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On 24 Nov 2004 at 14h11, Raj wrote:

Hi, 

> - Why is it taking a long time to unmount ?

It's syncing last writes

> - Is it safe to remove the pen drive from it's slot when the umount is still in
>   progress ?? ( I tried this the first time & maybe lucky me, the
> files copied were fine )

Lucky you :) If your key is fat or vfat, you could try these two patches 
and mount your USB key with -o sync option, your feedback interests me. 
It should make the copies to key slower, but the umount immediate.

-- 
Colin

[-- Attachment #2: fat_sync.patch --]
[-- Type: text/plain, Size: 2380 bytes --]

--- a/fs/fat/cache.c	2004-11-18 19:42:41.701778200 +0100
+++ b/fs/fat/cache.c	2004-11-18 18:40:25.000000000 +0100
@@ -271,6 +271,7 @@
 			mark_buffer_dirty(bh2);
 		}
 		mark_buffer_dirty(bh);
+
 		for (copy = 1; copy < sbi->fats; copy++) {
 			b = sbi->fat_start + (first >> sb->s_blocksize_bits)
 				+ sbi->fat_length * copy;
--- a/fs/fat/dir.c	2004-11-18 19:42:41.704777744 +0100
+++ b/fs/fat/dir.c	2004-11-18 14:36:44.000000000 +0100
@@ -736,6 +736,7 @@
 {
 	struct buffer_head *bh;
 	struct msdos_dir_entry *de;
+	struct super_block *sb;
 	__le16 date, time;
 
 	bh = fat_extend_dir(dir);
@@ -764,6 +765,11 @@
 	dir->i_atime = dir->i_ctime = dir->i_mtime = CURRENT_TIME;
 	mark_inode_dirty(dir);
 
+	sb = dir->i_sb;
+
+	if (sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
+
 	return 0;
 }
 
--- a/fs/fat/file.c	2004-10-18 23:53:44.000000000 +0200
+++ b/fs/fat/file.c	2004-11-18 14:57:03.000000000 +0100
@@ -74,21 +74,34 @@
 {
 	struct inode *inode = filp->f_dentry->d_inode;
 	int retval;
+	struct super_block *sb = inode->i_sb;
+	struct buffer_head *bh = NULL;
 
 	retval = generic_file_write(filp, buf, count, ppos);
 	if (retval > 0) {
 		inode->i_mtime = inode->i_ctime = CURRENT_TIME;
 		MSDOS_I(inode)->i_attrs |= ATTR_ARCH;
 		mark_inode_dirty(inode);
+		if (sb->s_flags & MS_SYNCHRONOUS) {
+			bh = sb_bread(sb, MSDOS_SB(sb)->fsinfo_sector);
+			if (bh != NULL) {
+				sync_dirty_buffer(bh);
+				brelse(bh);
+			} else {
+				BUG_ON(1);
+			}
+		}
 	}
 	return retval;
 }
 
 void fat_truncate(struct inode *inode)
 {
+	struct super_block *sb = inode->i_sb;
 	struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
 	const unsigned int cluster_size = sbi->cluster_size;
 	int nr_clusters;
+	struct buffer_head *bh = NULL;
 
 	/* 
 	 * This protects against truncating a file bigger than it was then
@@ -105,4 +118,8 @@
 	unlock_kernel();
 	inode->i_ctime = inode->i_mtime = CURRENT_TIME;
 	mark_inode_dirty(inode);
+	if (sb->s_flags & MS_SYNCHRONOUS) {
+		bh = sb_bread(sb, sbi->fsinfo_sector);
+		sync_dirty_buffer(bh);
+	}
 }
--- a/fs/fat/inode.c	2004-11-18 19:42:41.710776832 +0100
+++ b/fs/fat/inode.c	2004-11-18 15:00:55.000000000 +0100
@@ -1273,8 +1273,12 @@
 	}
 	spin_unlock(&sbi->inode_hash_lock);
 	mark_buffer_dirty(bh);
-	brelse(bh);
 	unlock_kernel();
+
+	if (sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
+	brelse(bh);
+
 	return 0;
 }
 

[-- Attachment #3: vfat_sync.patch --]
[-- Type: text/plain, Size: 2406 bytes --]

--- a/fs/vfat/namei.c	2004-10-18 23:54:37.000000000 +0200
+++ b/fs/vfat/namei.c	2004-11-18 18:41:52.000000000 +0100
@@ -743,6 +743,8 @@
 	(*de)->adate = (*de)->cdate = (*de)->date;
 
 	mark_buffer_dirty(*bh);
+	if (dir->i_sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(*bh);
 
 	/* slots can't be less than 1 */
 	sinfo_out->long_slots = slots - 1;
@@ -844,7 +846,6 @@
 	if (res < 0)
 		goto out;
 	inode = fat_build_inode(sb, de, sinfo.i_pos, &res);
-	brelse(bh);
 	if (!inode)
 		goto out;
 	res = 0;
@@ -854,7 +855,10 @@
 	dir->i_version++;
 	dentry->d_time = dentry->d_parent->d_inode->i_version;
 	d_instantiate(dentry,inode);
+	if (sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
 out:
+	brelse(bh);
 	unlock_kernel();
 	return res;
 }
@@ -871,6 +875,7 @@
 	mark_inode_dirty(dir);
 	de->name[0] = DELETED_FLAG;
 	mark_buffer_dirty(bh);
+
 	/* remove the longname */
 	offset = sinfo->longname_offset; de = NULL;
 	for (i = sinfo->long_slots; i > 0; --i) {
@@ -880,6 +885,9 @@
 		de->attr = ATTR_NONE;
 		mark_buffer_dirty(bh);
 	}
+	if (dir->i_sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
+
 	brelse(bh);
 }
 
@@ -903,7 +911,7 @@
 	dentry->d_inode->i_mtime = dentry->d_inode->i_atime = CURRENT_TIME;
 	fat_detach(dentry->d_inode);
 	mark_inode_dirty(dentry->d_inode);
-	/* releases bh */
+	/* releases bh and syncs it if necessary */
 	vfat_remove_entry(dir,&sinfo,bh,de);
 	dir->i_nlink--;
 out:
@@ -926,7 +934,7 @@
 	dentry->d_inode->i_mtime = dentry->d_inode->i_atime = CURRENT_TIME;
 	fat_detach(dentry->d_inode);
 	mark_inode_dirty(dentry->d_inode);
-	/* releases bh */
+	/* releases bh and syncs it if necessary */
 	vfat_remove_entry(dir,&sinfo,bh,de);
 out:
 	unlock_kernel();
@@ -956,6 +964,10 @@
 	dir->i_version++;
 	dir->i_nlink++;
 	inode->i_nlink = 2; /* no need to mark them dirty */
+
+	if (sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
+	
 	res = fat_new_dir(inode, dir, 1);
 	if (res < 0)
 		goto mkdir_failed;
@@ -972,7 +984,7 @@
 	inode->i_mtime = inode->i_atime = CURRENT_TIME;
 	fat_detach(inode);
 	mark_inode_dirty(inode);
-	/* releases bh */
+	/* releases bh ands syncs if necessary */
 	vfat_remove_entry(dir,&sinfo,bh,de);
 	iput(inode);
 	dir->i_nlink--;
@@ -1057,6 +1069,8 @@
 			new_dir->i_nlink++;
 			mark_inode_dirty(new_dir);
 		}
+		if (new_dir->i_sb->s_flags & MS_SYNCHRONOUS)
+			sync_dirty_buffer(dotdot_bh);
 	}
 
 rename_done:

Re: Delay in unmounting a USB pen drive

[Raj]

> Lucky you :) If your key is fat or vfat, you could try these two patches
> and mount your USB key with -o sync option, your feedback interests me.
> It should make the copies to key slower, but the umount immediate.

Yes, my key is vfat. I shall try out the vfat patch & post the
results. It might
take some time, coz i am building a 2.9 gnome right now. Will keep the list
posted with the results.

Thx

-- 
######
raj
######

Re: Delay in unmounting a USB pen drive

[Colin Leroy]

On 24 Nov 2004 at 15h11, Raj wrote:

Hi, 

> > Lucky you :) If your key is fat or vfat, you could try these two patches
> > and mount your USB key with -o sync option, your feedback interests me.
> > It should make the copies to key slower, but the umount immediate.
> 
> Yes, my key is vfat. I shall try out the vfat patch & post the
> results. It might take some time, coz i am building a 2.9 gnome right 
> now. Will keep the list posted with the results.

Apply also the fat patch, vfat uses fat.

-- 
Colin

Re: Delay in unmounting a USB pen drive

[bert hubert]

On Wed, Nov 24, 2004 at 02:55:57PM +0530, Raj wrote:
> SuSE kernel 2.6.5:
> 
> My USB pen drive has a vfat FS. When i transfer some files & try to
> unmount the drive ( umount /mnt ) , the command appears hung. CTRL+C also
> does not work. Only later did i realise that it was actually taking a
> longer time ( 10 - 15 sec )
> to unmount.

The data is only actually being written to the pen drive when you unmount.
To make unmounting fast, either mount with -o sync, or run 'sync' before
umounting.


> - Is it safe to remove the pen drive from it's slot when the umount is still in
>   progress ?? ( I tried this the first time & maybe lucky me, the
> files copied were fine )

Try reading them - you will find emtpiness.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO