All of lore.kernel.org
 help / color / mirror / Atom feed
* Delay in unmounting a USB pen drive
@ 2004-11-24  9:25 Raj
  2004-11-24  9:34 ` Anton Altaparmakov
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Raj @ 2004-11-24  9:25 UTC (permalink / raw)
  To: Linux Kernel Mailing List

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
######

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Delay in unmounting a USB pen drive
  2004-11-24  9:25 Delay in unmounting a USB pen drive Raj
@ 2004-11-24  9:34 ` Anton Altaparmakov
  2004-11-24  9:50   ` Raj
  2004-11-24  9:38 ` Colin Leroy
  2004-11-24 10:17 ` bert hubert
  2 siblings, 1 reply; 7+ messages in thread
From: Anton Altaparmakov @ 2004-11-24  9:34 UTC (permalink / raw)
  To: Raj; +Cc: lkml

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/


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Delay in unmounting a USB pen drive
  2004-11-24  9:25 Delay in unmounting a USB pen drive Raj
  2004-11-24  9:34 ` Anton Altaparmakov
@ 2004-11-24  9:38 ` Colin Leroy
  2004-11-24  9:52   ` Raj
  2004-11-24 10:17 ` bert hubert
  2 siblings, 1 reply; 7+ messages in thread
From: Colin Leroy @ 2004-11-24  9:38 UTC (permalink / raw)
  To: Raj; +Cc: Linux Kernel Mailing List

[-- 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:

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Delay in unmounting a USB pen drive
  2004-11-24  9:34 ` Anton Altaparmakov
@ 2004-11-24  9:50   ` Raj
  0 siblings, 0 replies; 7+ messages in thread
From: Raj @ 2004-11-24  9:50 UTC (permalink / raw)
  To: Anton Altaparmakov; +Cc: lkml

> 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
######

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Delay in unmounting a USB pen drive
  2004-11-24  9:38 ` Colin Leroy
@ 2004-11-24  9:52   ` Raj
  2004-11-24 10:06     ` Colin Leroy
  0 siblings, 1 reply; 7+ messages in thread
From: Raj @ 2004-11-24  9:52 UTC (permalink / raw)
  To: Colin Leroy; +Cc: Linux Kernel Mailing List

> 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
######

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Delay in unmounting a USB pen drive
  2004-11-24  9:52   ` Raj
@ 2004-11-24 10:06     ` Colin Leroy
  0 siblings, 0 replies; 7+ messages in thread
From: Colin Leroy @ 2004-11-24 10:06 UTC (permalink / raw)
  To: Raj; +Cc: Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Delay in unmounting a USB pen drive
  2004-11-24  9:25 Delay in unmounting a USB pen drive Raj
  2004-11-24  9:34 ` Anton Altaparmakov
  2004-11-24  9:38 ` Colin Leroy
@ 2004-11-24 10:17 ` bert hubert
  2 siblings, 0 replies; 7+ messages in thread
From: bert hubert @ 2004-11-24 10:17 UTC (permalink / raw)
  To: Raj; +Cc: Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2004-11-24 12:23 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-24  9:25 Delay in unmounting a USB pen drive Raj
2004-11-24  9:34 ` Anton Altaparmakov
2004-11-24  9:50   ` Raj
2004-11-24  9:38 ` Colin Leroy
2004-11-24  9:52   ` Raj
2004-11-24 10:06     ` Colin Leroy
2004-11-24 10:17 ` bert hubert

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.