fsync is the call to flush a buffer to disk so I think commenting it out would be ill advised unless you know what you're doing. You pay a small penalty for flushing to disk more often in most cases(see http://linux.die.net/man/2/fsync).
As well: "A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use *fsync<http://linux.die.net/man/2/fsync> (2)*. (It will depend on the disk hardware at this point.)" http://linux.die.net/man/2/fsync http://linux.die.net/man/2/close My suspicion is that if you don't call fsync, it might live in device memory until the kernel decides to flush it to disk. If you restart your device you or it crashes, you might very well loose the data that's stored in memory that hasn't yet been flushed. You might check how often, and how much data it flushes(every 100kb, every 5mb? timer?) and adjust to see if you get an improvement by making less calls to fsync, but that's speculation that you would get an improvement and is based on the implementation. Extra code seems like it's simply enforcing that only one client can write to disk at a time. Luke On Monday, October 8, 2012 11:20:06 AM UTC+2, Mike wrote: > > Hi Everyone, > I am working on improving the MTP write performance of devices in general. > I came across this code in kernel/fs/sync.c > 178<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=fs/sync.c;h=14eefeb44636bd1e24240ae09fe0dd046ed013fa;hb=0e51793e162ca432fc5f04178cf82b80a92c2659#l178>int > vfs_fsync_range(struct file *file, loff_t start, loff_t end, int datasync) > 179<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=fs/sync.c;h=14eefeb44636bd1e24240ae09fe0dd046ed013fa;hb=0e51793e162ca432fc5f04178cf82b80a92c2659#l179>{ > 180<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=fs/sync.c;h=14eefeb44636bd1e24240ae09fe0dd046ed013fa;hb=0e51793e162ca432fc5f04178cf82b80a92c2659#l180> > if (!file->f_op || !file->f_op->fsync) > 181<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=fs/sync.c;h=14eefeb44636bd1e24240ae09fe0dd046ed013fa;hb=0e51793e162ca432fc5f04178cf82b80a92c2659#l181> > return -EINVAL; > 182<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=fs/sync.c;h=14eefeb44636bd1e24240ae09fe0dd046ed013fa;hb=0e51793e162ca432fc5f04178cf82b80a92c2659#l182> > return file->f_op->fsync(file, start, end, datasync); > 183<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=fs/sync.c;h=14eefeb44636bd1e24240ae09fe0dd046ed013fa;hb=0e51793e162ca432fc5f04178cf82b80a92c2659#l183>} > 184<http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=fs/sync.c;h=14eefeb44636bd1e24240ae09fe0dd046ed013fa;hb=0e51793e162ca432fc5f04178cf82b80a92c2659#l184>EXPORT_SYMBOL(vfs_fsync_range); > > can someone point out what happens if I disable this code, as I see good > improvement in performance if I disable this. > > Also this code has been changed in Samung's Kernel code > int vfs_fsync_range(struct file *file, loff_t start, loff_t end, int > datasync) { struct address_space *mapping = file->f_mapping; int err, ret; > if (!file->f_op || !file->f_op->fsync) { ret = -EINVAL; goto out; } ret = > filemap_write_and_wait_range(mapping, start, end); /* * We need to protect > against concurrent writers, which could cause * livelocks in > fsync_buffers_list(). */ mutex_lock(&mapping->host->i_mutex); err = > file->f_op->fsync(file, datasync); if (!ret) ret = err; > mutex_unlock(&mapping->host->i_mutex); out: return ret; } > > Can anyone point out what the additional code is doing and why. (In case > you have seen this) > Also please suggest any other option to improve MTP write performance > > Thanks for your help > Mike > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
