Messages in this thread | | | Date | Tue, 28 Feb 2006 11:10:32 -0800 | From | Andrew Morton <> | Subject | Re: o_sync in vfat driver |
| |
Chris Mason <mason@suse.com> wrote: > > On Monday 27 February 2006 18:12, Andrew Morton wrote: > > > We don't know that the same number of same-sized write()s were happening in > > each case. > > > > There's been some talk about implementing fsync()-on-file-close for this > > problem, and some protopatches. But nothing final yet. > > Here's the patch I'm using in -suse right now. What I want to do is make a > much more generic -o flush, but it'll still need a few bits in individual > filesystem to kick off metadata writes quickly. > > The basic goal behind the code is to trigger writes without waiting for both > data and metadata. If the user is watching the memory stick, when the > little light stops flashing all the data and metadata will be on disk. > > It also generally throttles userland a little during file release. This > could be changed to throttle for each page dirtied, but most users I > asked liked the current setup better. > > ... > > +static int > +fat_file_release(struct inode *inode, struct file *filp)
On a single line, please.
> + if (MSDOS_SB(inode->i_sb)->options.flush) {
Did you consider making `-o flush' a generic mount option rather than msdos-only?
I guess there isn't a lot of demand for this for other filesystems, and having an ignored option like this is a bit misleading...
> +void > +writeback_inode(struct inode *inode) > +{ > + > + struct address_space *mapping = inode->i_mapping; > + struct writeback_control wbc = { > + .sync_mode = WB_SYNC_NONE, > + .nr_to_write = 0, > + }; > + sync_inode(inode, &wbc); > + filemap_fdatawrite(mapping);
I think that filemap_fdatawrite() will be a no-op?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |