On Sun, Feb 07, 2016 at 12:19:06PM -0500, Alan Stern wrote:
> On Sat, 6 Feb 2016, Oliver Neukum wrote:
>
> > > In theory, the copy command in Windows shouldn't need to wait either.
> > > But then you'd run into trouble if you unplugged the USB device without
> > > first clicking on the "Safely remove hardware" button -- which
> > > essentially does a sync.
> >
> > Well, not fully. Linux knows two modes. Full caching and totally
> > synchronous operations. It seems to me we could do better.
> > Like starting the write as soon as dirty blocks appear and do an
> > fsync upon close.
>
> Even that wouldn't really do just what Marc would like. It would be
> nice to have a version of cp that would display a progress indicator,
> and every (say) 5% would do fdatasync. Plus, of course, fsync upon
> close.
>
> My point being that this doesn't require any changes to the kernel --
> neither the filesystem layer nor the USB stack. It requires changes
> to the cp program. Or a new (maybe even graphical) version of cp.
If the kernel allowed a 3rd mounting mode between sync and async where
sync would be acked right away, but would be delayed for up to 1-5sec
(maybe even some -o sync=2) so that io requests can be batched up and
you get something close enough to sync for most people, this would
likely be the automagic mode that works for most users (a bit like
relatime came to save the day between atime and noatime).
Now, the =2 may not be needed if some quick tests show that =1 fixes the
cp performance problem, it can just be hardcoded, and the option called
something like -o delaysync or somesuch.
This would then work with all userland without any modifications.
The thing is userland is written for the common case, and telling cp it
should now sync every few seconds would not fly for many users, and
having it be in the business to detect that it's writing to usb flash,
and switch to a special sync often mode, is not exactly going to happen
(without counting that you'd have to fix dozens of tools outside of cp).
This is why a kernel solution geared at some devices like flash storage,
would seem to be the simplest option by far.
Is the way sync/async is treated inside usb-storage, some other USB
module, or outside of the usb stack altogether?
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
