# Can't mount VFAT "nosync"?

## benny1967

Hello,

having read about the issues with USB-devices mounted "sync", I wanted to try the nosync-option. (I've always had trouble with copying files, sso I thought it would be a good idea anyway.)

The device has an entry in fstab, so I simply changed it from

/dev/sda1               /media/USB      vfat            noauto,rw,users        0 0

to

/dev/sda1               /media/USB      vfat            noauto,rw,users,nosync        0 0

I thought this should do. Wrong.

When I try to mount the device now, I get an error and dmesg shows:

FAT: Unrecognized mount option "nosync" or missing value

What's wrong? Obviously, everybody's moving to nosync with their USB-devices, and I assume that most of those are FAT-formatted. I cannot believe you can't mount FAT nosync... Any suggestions?

Oh yes, my kernel is 2.6.15-gentoo-r1

[/quote]

----------

## SinoTech

Think the option you are searching for is named "async" and not "nosync".

 *'man mount' wrote:*   

> 
> 
>               async  All I/O to the file system should be done asynchronously.
> 
> 

 

Anyway, I am not sure if that has any affect to your mounted device, cause according to the man page the "sync" option has only affect to ext2, ext3 and ufs filesystems, and so I assume that "async" is the default behaviour.

 *'man mount' wrote:*   

> 
> 
> [...]
> 
> The following options apply to any file system that is being mounted (but not every file system  actually
> ...

 

Regards,

Sino

----------

## Philantrop

 *benny1967 wrote:*   

> having read about the issues with USB-devices mounted "sync", I wanted to try the nosync-option. (I've always had trouble with copying files, sso I thought it would be a good idea anyway.)

 

What are those troubles? Are we talking about files you copied onto the USB device that were either corrupted or are not there at all?

----------

## nephros

 *Philantrop wrote:*   

>  *benny1967 wrote:*   having read about the issues with USB-devices mounted "sync", I wanted to try the nosync-option. (I've always had trouble with copying files, sso I thought it would be a good idea anyway.) 
> 
> What are those troubles? Are we talking about files you copied onto the USB device that were either corrupted or are not there at all?

 

I think he is referring to devices like USB thumbdrives, which can get written to only a certain number of times.

As any write operation to FAT filesystems must alter the FAT (file access table), and the FAT is always at the same physical place on the partition, a "sync" mount causes severe stress to the device.

An async mounted drive will bundle the writes to the area the FAT is at resulting in less writes and therefore longer lifetime of the device.

----------

## Philantrop

Well, he talked about file copying problems so I think he's referring to something more specific. 

Anyway, the default is to mount asynchronously. (Sinotech, it is possible to "mount -o sync" vfat fs', btw.) The trouble that might cause is if he disconnects the device before the data gets actually written. That's what I was thinking of.

----------

## benny1967

 *Philantrop wrote:*   

>  *benny1967 wrote:*   having read about the issues with USB-devices mounted "sync", I wanted to try the nosync-option. (I've always had trouble with copying files, sso I thought it would be a good idea anyway.) 
> 
> What are those troubles? Are we talking about files you copied onto the USB device that were either corrupted or are not there at all?

 

We're talking about 2 things   :Smile: 

a) files I copied onto the USB device that were either corrupted or are not there at all: yes, this is what's happening here.

b) the warnings everywhere in this forum that "sync" shortens the lifespan of flash-based devices because of too many writes. my device is new, but I think I should take good care of it.

----------

## benny1967

 *nephros wrote:*   

> I think he is referring to devices like USB thumbdrives, which can get written to only a certain number of times.
> 
> As any write operation to FAT filesystems must alter the FAT (file access table), and the FAT is always at the same physical place on the partition, a "sync" mount causes severe stress to the device.
> 
> An async mounted drive will bundle the writes to the area the FAT is at resulting in less writes and therefore longer lifetime of the device.

 

Right, that's what I'm talking about. I wonder now if it's 'nosync' or 'async'...? All the other postings I read used the wording "nosnyc" - but then they never referred to fstab, only to HAL. ...? 

How can I tell which is what I want and which is default anyway? Somewhere along my searches through google yesterday I read that with the "right" option, I wouldnt get a progress bar in Gnome when copying files because nautilus has no information on how much of the file if already transferred; if this is correct, I certainly have the wrong setting: the progress bar stays on for minutes.

----------

## Philantrop

Ok, now it's all clear.

Yes, to mount your USB drive in "sync" mode is not the best idea. The default is to mount asynchronously so you don't have to change anything. You can check that for yourself by simply issuing "mount". You'll see there is no "sync" among the displayed mount options. (The part in brackets.)

To verify that, feel free to "mount -o sync /dev/<device node> /mnt" and the issue "mount" again. This time there will be "sync" displayed (among others).

The option's name is really "async" if we're talking about mounting. Maybe in hal or ivman there's a "nosync" option (I'm using dbus/hal/ivman myself) but to set it would simply be redundant. ivman, too, mounts asynchronously by default. 

The progress bar in Gnome is definitely not an indicator for anything. 

The problem with corrupted or missing files is simple: "async" is the culprit. (Yes, there's a trade-off to everything in life. ;-) ) The data gets written asynchronously, meaning that everything looks like the operation has successfully finished even though the data has not yet (completely) been written to your USB drive. To avoid such issues, you can use the "sync" command which will flush out all unwritten buffers to your drive. That's not as bad as mounting synchronously and makes sure your data will be fine.

----------

## benny1967

Philantrop, thank you very much. I was really getting confused with all this.

 *Philantrop wrote:*   

> The problem with corrupted or missing files is simple: "async" is the culprit. (Yes, there's a trade-off to everything in life.  ) The data gets written asynchronously, meaning that everything looks like the operation has successfully finished even though the data has not yet (completely) been written to your USB drive. To avoid such issues, you can use the "sync" command which will flush out all unwritten buffers to your drive. That's not as bad as mounting synchronously and makes sure your data will be fine.

 

Shouldn't it be enough to issue a umount before disconnecting the device? I'd have believed that umount checks if the device can be safely removed, taking into account unfinished writ operations.

I'm asking because I always unmount manually, therefore I believed an additional "sync" (=command line, not mount option  :Very Happy: ) would be unnecessary.

----------

## Philantrop

Yes, an umount implicitly syncs as well. I'm so used to auto-mounting with dbus/hal/ivman these days that I sometimes forget that there's life beyond those three. ;-)

If you unmount manually, you shouldn't have any problems with file corruption, etc. either. If you use auto-mounting, this might be different.

----------

