Hi All,
I am writing several GB of data to a flash drive. It won't dismount as it is stikll flushing.
# sync /dev/sdc1
comes back instantly.
Is there a better command to see if the flush is finished?
Many thanks, -T
On 2020-04-26 16:50, ToddAndMargo via users wrote:
Hi All,
I am writing several GB of data to a flash drive. It won't dismount as it is stikll flushing.
# sync /dev/sdc1
comes back instantly.
Is there a better command to see if the flush is finished?
Many thanks, -T
It did finally let me dismount
On 26Apr2020 20:00, Tom Horsley horsley1953@gmail.com wrote:
On Sun, 26 Apr 2020 16:50:57 -0700 ToddAndMargo via users wrote:
Is there a better command to see if the flush is finished?
The umount should hang till the writes are done. That's the way it always works for me.
Definitely. But so should the sync. Something's odd there. That said, I have never done sync with a device name. ToddAndMargo: was your device name correct? Syncing the wrong devie might well come back instantly.
Cheers, Cameron Simpson cs@cskk.id.au
just "sync" should work as it will sync the whole system, and generally the other filesystems have little or no data in them so sync fast.
sync <file> syncs a file, and the data is not queued up on the file/device /dev/sdc1 (a tiny amount is, but that will sync fast) the data is queue on the filesystem that sits ontop /dev/sdc1.
On Sun, Apr 26, 2020 at 7:37 PM Cameron Simpson cs@cskk.id.au wrote:
On 26Apr2020 20:00, Tom Horsley horsley1953@gmail.com wrote:
On Sun, 26 Apr 2020 16:50:57 -0700 ToddAndMargo via users wrote:
Is there a better command to see if the flush is finished?
The umount should hang till the writes are done. That's the way it always works for me.
Definitely. But so should the sync. Something's odd there. That said, I have never done sync with a device name. ToddAndMargo: was your device name correct? Syncing the wrong devie might well come back instantly.
Cheers, Cameron Simpson cs@cskk.id.au _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 2020-04-26 17:36, Cameron Simpson wrote:
On 26Apr2020 20:00, Tom Horsley horsley1953@gmail.com wrote:
On Sun, 26 Apr 2020 16:50:57 -0700 ToddAndMargo via users wrote:
Is there a better command to see if the flush is finished?
The umount should hang till the writes are done. That's the way it always works for me.
Definitely. But so should the sync. Something's odd there. That said, I have never done sync with a device name. ToddAndMargo: was your device name correct? Syncing the wrong devie might well come back instantly.
Cheers, Cameron Simpson cs@cskk.id.au
My bad. As soon as I exited the krusader window inside the stick, I could unmount
On 26Apr2020 18:36, ToddAndMargo ToddAndMargo@zoho.com wrote:
On 2020-04-26 17:36, Cameron Simpson wrote:
On 26Apr2020 20:00, Tom Horsley horsley1953@gmail.com wrote:
On Sun, 26 Apr 2020 16:50:57 -0700 ToddAndMargo via users wrote:
Is there a better command to see if the flush is finished?
The umount should hang till the writes are done. That's the way it always works for me.
Definitely. But so should the sync. Something's odd there. That said, I have never done sync with a device name. ToddAndMargo: was your device name correct? Syncing the wrong devie might well come back instantly.
My bad. As soon as I exited the krusader window inside the stick, I could unmount
Aha, device busy. A hand umount from the command line will complain about that. And lsof will often tell you what's got its hooks in, IIRC. Classic example for me is the stray idle shell cded into the volume.
Cheers, Cameron Simpson cs@cskk.id.au
On Sun, 2020-04-26 at 18:36 -0700, ToddAndMargo via users wrote:
As soon as I exited the krusader window inside the stick, I could unmount
That kind of thing has been an annoying bug for ages. You have file browsers that have right-click options allowing you to unmount something from their directory tree. Yet, when you try to use it, it fails (usually because that directory is being shown in the adjacent panel).
On Sun, 26 Apr 2020 19:46:15 -0500 Roger Heflin wrote:
just "sync" should work as it will sync the whole system, and generally the other filesystems have little or no data in them so sync fast.
Unless you leave your external USB drive plugged in, in which case it takes 30 seconds to spin up so it can decide there is nothing to sync :-).
On Sun, Apr 26, 2020 at 04:50:57PM -0700, ToddAndMargo via users wrote:
Hi All,
I am writing several GB of data to a flash drive. It won't dismount as it is stikll flushing.
# sync /dev/sdc1
comes back instantly.
Is there a better command to see if the flush is finished?
Don't know the answer, but it is not sync. Sync queues the flushes then returns. Does not wait until they have been done.
Jon
Many thanks, -T _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
End of included message <<<
On 27Apr2020 14:42, Jon LaBadie jonfu@jgcomp.com wrote:
On Sun, Apr 26, 2020 at 04:50:57PM -0700, ToddAndMargo via users wrote:
I am writing several GB of data to a flash drive. It won't dismount as it is stikll flushing.
# sync /dev/sdc1
comes back instantly.
Is there a better command to see if the flush is finished?
Don't know the answer, but it is not sync. Sync queues the flushes then returns. Does not wait until they have been done.
Sync does wait, that's what its name means.
The OS will be queuing things anyway because it is in its interest to minimise the dirty pages in memory (more free pages means more ability to accomodate needs, and fewer dirty pages means less fs damage in case of a crash).
Cheers, Cameron Simpson cs@cskk.id.au
-
Cameron Simpson -
Jon LaBadie -
Roger Heflin -
Tim -
ToddAndMargo -
Tom Horsley