Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
Many thanks, -T
Hi, when the writing on my sticks is done I try to unmount, F28 says then there is still activity don't remove, when the activity is done now the system says, You can remove. But there might be someone with more knowledge then I, who can give You some code to check the activity task.
Kind regards
-----Ursprüngliche Mitteilung----- Von: ToddAndMargo via users users@lists.fedoraproject.org An: Community support for Fedora users users@lists.fedoraproject.org Cc: ToddAndMargo ToddAndMargo@zoho.com Verschickt: Di, 6. Nov. 2018 6:04 Betreff: Sticks with not lights
Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
Many thanks, -T
ToddAndMargo:
I am struggling with this one as well. To the best of my googling, it seems that the "sync" command needs to be done before clicking "safely remove" (or whatever). Documentation also says that "sudo umount <stick>" should do it, but I have experienced at least one instance where it didn't seem like it worked ... not certain what happened.
I am still testing but I "think" I am seeing that doing a "safely remove" and then a sync before physically removing gives best result (as in no pop-up warning). Do not understand why this is.
Not happy that the led light is vanishing on newer sticks ...
The "sync" command does not appear to be all that nice to the stick and there doesn't appear to be any way to isolate the "sync" to the stick.
I would hope that someone on this user-list who is more knowledgeable will correct me with a better way.
Best, Paul
On 11/05/2018 09:03 PM, ToddAndMargo via users wrote:
Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
Many thanks, -T
On 11/5/18 10:03 PM, Paul Allen Newell wrote:
ToddAndMargo:
I am struggling with this one as well. To the best of my googling, it seems that the "sync" command needs to be done before clicking "safely remove" (or whatever). Documentation also says that "sudo umount <stick>" should do it, but I have experienced at least one instance where it didn't seem like it worked ... not certain what happened.
I am still testing but I "think" I am seeing that doing a "safely remove" and then a sync before physically removing gives best result (as in no pop-up warning). Do not understand why this is.
Not happy that the led light is vanishing on newer sticks ...
The "sync" command does not appear to be all that nice to the stick and there doesn't appear to be any way to isolate the "sync" to the stick.
If you issue the sync command, give it a "-f" and specify a file on that stick (perhaps the root of the filesystem):
sync -f /flash/mountpoint/
then it should only sync the filesystem on /flash/mountpoint.
I would hope that someone on this user-list who is more knowledgeable will correct me with a better way.
That's the best I can offer. Remember that USB and FLASH are a lot slower than IDE/SATA/SAS stuff.
On 11/05/2018 09:03 PM, ToddAndMargo via users wrote:
Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
As far as I know, there's no way to reliably tell if everything has been flushed to the media. The sync command above shouldn't return until it's complete, so if you include it in your script, you should be OK. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - You know the old saying--any technology sufficiently advanced is - - indistinguishable from a Perl script - - --Programming Perl, 2nd Edition - ----------------------------------------------------------------------
On 11/5/18 10:03 PM, Paul Allen Newell wrote:
ToddAndMargo:
I am struggling with this one as well. To the best of my googling, it seems that the "sync" command needs to be done before clicking "safely remove" (or whatever). Documentation also says that "sudo umount <stick>" should do it, but I have experienced at least one instance where it didn't seem like it worked ... not certain what happened.
I am still testing but I "think" I am seeing that doing a "safely remove" and then a sync before physically removing gives best result (as in no pop-up warning). Do not understand why this is.
Not happy that the led light is vanishing on newer sticks ...
The "sync" command does not appear to be all that nice to the stick and there doesn't appear to be any way to isolate the "sync" to the stick.
If you issue the sync command, give it a "-f" and specify a file on that stick (perhaps the root of the filesystem):
sync -f /flash/mountpoint/
then it should only sync the filesystem on /flash/mountpoint.
I would hope that someone on this user-list who is more knowledgeable will correct me with a better way.
That's the best I can offer. Remember that USB and FLASH are a lot slower than IDE/SATA/SAS stuff.
On 11/05/2018 09:03 PM, ToddAndMargo via users wrote:
Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
As far as I know, there's no way to reliably tell if everything has been flushed to the media. The sync command above shouldn't return until it's complete, so if you include it in your script, you should be OK. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - You know the old saying--any technology sufficiently advanced is - - indistinguishable from a Perl script - - --Programming Perl, 2nd Edition - ----------------------------------------------------------------------
On 11/06/2018 09:56 AM, Rick Stevens wrote:
On 11/5/18 10:03 PM, Paul Allen Newell wrote:
ToddAndMargo:
I am struggling with this one as well. To the best of my googling, it seems that the "sync" command needs to be done before clicking "safely remove" (or whatever). Documentation also says that "sudo umount <stick>" should do it, but I have experienced at least one instance where it didn't seem like it worked ... not certain what happened.
I am still testing but I "think" I am seeing that doing a "safely remove" and then a sync before physically removing gives best result (as in no pop-up warning). Do not understand why this is.
Not happy that the led light is vanishing on newer sticks ...
The "sync" command does not appear to be all that nice to the stick and there doesn't appear to be any way to isolate the "sync" to the stick.
If you issue the sync command, give it a "-f" and specify a file on that stick (perhaps the root of the filesystem):
sync -f /flash/mountpoint/
then it should only sync the filesystem on /flash/mountpoint.
I would hope that someone on this user-list who is more knowledgeable will correct me with a better way.
That's the best I can offer. Remember that USB and FLASH are a lot slower than IDE/SATA/SAS stuff.
On 11/05/2018 09:03 PM, ToddAndMargo via users wrote:
Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
As far as I know, there's no way to reliably tell if everything has been flushed to the media. The sync command above shouldn't return until it's complete, so if you include it in your script, you should be OK.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
-- You know the old saying--any technology sufficiently advanced is -
indistinguishable from a Perl script ---Programming Perl, 2nd Edition -
Rick:
Thanks for reply. I went through a bunch on man pages that do not list the -f option. After getting your email, I went looking for a bunch more and finally found one that had the -f and -d option.
I note that 'sync --help' only provides 'Usage: sync [OPTION]' without listing what the options are. I have just followed their suggestion of running "info coreutils 'sync invocation'" which gives alot of options.
Not certain why these options are more readily visible. I probably should have dug deeper but after a bunch of online docs showing no options I just figured there weren't any.
Paul
On Tue, 6 Nov 2018 11:07:22 -0800, Paul Allen Newell pnewell0705@gmail.com wrote:
Rick:
Thanks for reply. I went through a bunch on man pages that do not list the -f option. After getting your email, I went looking for a bunch more and finally found one that had the -f and -d option.
I note that 'sync --help' only provides 'Usage: sync [OPTION]' without listing what the options are. I have just followed their suggestion of running "info coreutils 'sync invocation'" which gives alot of options.
Not certain why these options are more readily visible. I probably should have dug deeper but after a bunch of online docs showing no options I just figured there weren't any.
Paul
On both Fedora 28 and 29 (I don't have any older versions available), "man sync" describes the -f option and "sync --help" returns the following:
Usage: sync [OPTION] [FILE]... Synchronize cached writes to persistent storage
If one or more files are specified, sync only them, or their containing file systems.
-d, --data sync only file data, no unneeded metadata -f, --file-system sync the file systems that contain the files --help display this help and exit --version output version information and exit
GNU coreutils online help: https://www.gnu.org/software/coreutils/ Full documentation at: https://www.gnu.org/software/coreutils/sync or available locally via: info '(coreutils) sync invocation'
The link to the coreutils documentation gives more detail. (The man page also points to that.) I'm not sure why you don't think the options are readily visible, unless you're working on non-Fedora (or even non-Linux) systems.
On 11/6/18 11:46 AM, George Avrunin wrote:
On Tue, 6 Nov 2018 11:07:22 -0800, Paul Allen Newell pnewell0705@gmail.com wrote:
Rick:
Thanks for reply. I went through a bunch on man pages that do not list the -f option. After getting your email, I went looking for a bunch more and finally found one that had the -f and -d option.
I note that 'sync --help' only provides 'Usage: sync [OPTION]' without listing what the options are. I have just followed their suggestion of running "info coreutils 'sync invocation'" which gives alot of options.
Not certain why these options are more readily visible. I probably should have dug deeper but after a bunch of online docs showing no options I just figured there weren't any.
Paul
On both Fedora 28 and 29 (I don't have any older versions available), "man sync" describes the -f option and "sync --help" returns the following:
Usage: sync [OPTION] [FILE]... Synchronize cached writes to persistent storage
If one or more files are specified, sync only them, or their containing file systems.
-d, --data sync only file data, no unneeded metadata -f, --file-system sync the file systems that contain the files --help display this help and exit --version output version information and exitGNU coreutils online help: https://www.gnu.org/software/coreutils/ Full documentation at: https://www.gnu.org/software/coreutils/sync or available locally via: info '(coreutils) sync invocation'
The link to the coreutils documentation gives more detail. (The man page also points to that.) I'm not sure why you don't think the options are readily visible, unless you're working on non-Fedora (or even non-Linux) systems.
Did a bit of snooping with VMs I have with the following results:
OS "man sync" "sync --help" --------------- --------------- ------------- F26 Full options Full options F27 Full options Full options F28 Full options Full options F29 Full options Full options CentOS 7 No options No options Ubuntu 17 Full options Full options Ubuntu 18 Full options Full options
So, of the seven OSes I checked, only CentOS 7 didn't offer a full man page or show the options with "--help". Weird. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Memory is the second thing to go, but I can't remember the first! - ----------------------------------------------------------------------
On 11/06/2018 11:46 AM, George Avrunin wrote:
On Tue, 6 Nov 2018 11:07:22 -0800, Paul Allen Newell pnewell0705@gmail.com wrote:
Not certain why these options are more readily visible. I probably should have dug deeper but after a bunch of online docs showing no options I just figured there weren't any.
Paul
The link to the coreutils documentation gives more detail. (The man page also points to that.) I'm not sure why you don't think the options are readily visible, unless you're working on non-Fedora (or even non-Linux) systems.
I was using Google to search for Linux (all flavors) documentation ... as I said I realize that I should have dug deeper. Apologies.
On 11/6/18 12:40 PM, Paul Allen Newell wrote:
On 11/06/2018 11:46 AM, George Avrunin wrote:
On Tue, 6 Nov 2018 11:07:22 -0800, Paul Allen Newell pnewell0705@gmail.com wrote:
Not certain why these options are more readily visible. I probably should have dug deeper but after a bunch of online docs showing no options I just figured there weren't any.
Paul
The link to the coreutils documentation gives more detail. (The man page also points to that.) I'm not sure why you don't think the options are readily visible, unless you're working on non-Fedora (or even non-Linux) systems.
I was using Google to search for Linux (all flavors) documentation ... as I said I realize that I should have dug deeper. Apologies.
No worries. Just was curious. What was the system you checked on that DIDN'T list the options? In my last email I showed seven systems, and only CentOS 7 didn't list them. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - IGNORE that man behind the keyboard! - - - The Wizard of OS - ----------------------------------------------------------------------
On 11/06/2018 01:05 PM, Rick Stevens wrote:
On 11/6/18 12:40 PM, Paul Allen Newell wrote:
On 11/06/2018 11:46 AM, George Avrunin wrote:
On Tue, 6 Nov 2018 11:07:22 -0800, Paul Allen Newell pnewell0705@gmail.com wrote:
Not certain why these options are more readily visible. I probably should have dug deeper but after a bunch of online docs showing no options I just figured there weren't any.
Paul
The link to the coreutils documentation gives more detail. (The man page also points to that.) I'm not sure why you don't think the options are readily visible, unless you're working on non-Fedora (or even non-Linux) systems.
I was using Google to search for Linux (all flavors) documentation ... as I said I realize that I should have dug deeper. Apologies.
No worries. Just was curious. What was the system you checked on that DIDN'T list the options? In my last email I showed seven systems, and only CentOS 7 didn't list them.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
-IGNORE that man behind the keyboard! -- The Wizard of OS -
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Rick:
This thread is hopelessly out-of-sync on my machine as this 1:05pm didn't arrive until 1:58pm and I sent a reply to your original at 1:24pm saying that "and wouldn't ya know it that I am running Centos 7 ..."
Paul
On 11/6/18 2:02 PM, Paul Allen Newell wrote:
On 11/06/2018 01:05 PM, Rick Stevens wrote:
On 11/6/18 12:40 PM, Paul Allen Newell wrote:
On 11/06/2018 11:46 AM, George Avrunin wrote:
On Tue, 6 Nov 2018 11:07:22 -0800, Paul Allen Newell pnewell0705@gmail.com wrote:
Not certain why these options are more readily visible. I probably should have dug deeper but after a bunch of online docs showing no options I just figured there weren't any.
Paul
The link to the coreutils documentation gives more detail. (The man page also points to that.) I'm not sure why you don't think the options are readily visible, unless you're working on non-Fedora (or even non-Linux) systems.
I was using Google to search for Linux (all flavors) documentation ... as I said I realize that I should have dug deeper. Apologies.
No worries. Just was curious. What was the system you checked on that DIDN'T list the options? In my last email I showed seven systems, and only CentOS 7 didn't list them.
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- - - IGNORE that man behind the keyboard! -
- - The Wizard of OS -
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Rick:
This thread is hopelessly out-of-sync on my machine as this 1:05pm didn't arrive until 1:58pm and I sent a reply to your original at 1:24pm saying that "and wouldn't ya know it that I am running Centos 7 ..."
Heheheheh! Yeah, I got that message at 1:24 local time (PST). Sorry, but I was in a meeting when it came in. Might not be your system...could be the Fedora list server. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Polygon: A dead parrot (With apologies to John Cleese) - ----------------------------------------------------------------------
On 11/5/18 10:03 PM, Paul Allen Newell wrote:
ToddAndMargo:
I am struggling with this one as well. To the best of my googling, it seems that the "sync" command needs to be done before clicking "safely remove" (or whatever). Documentation also says that "sudo umount <stick>" should do it, but I have experienced at least one instance where it didn't seem like it worked ... not certain what happened.
I am still testing but I "think" I am seeing that doing a "safely remove" and then a sync before physically removing gives best result (as in no pop-up warning). Do not understand why this is.
Not happy that the led light is vanishing on newer sticks ...
The "sync" command does not appear to be all that nice to the stick and there doesn't appear to be any way to isolate the "sync" to the stick.
I would hope that someone on this user-list who is more knowledgeable will correct me with a better way.
Best, Paul
On 11/05/2018 09:03 PM, ToddAndMargo via users wrote:
Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
This is the dismount part of my script:
sync; sync umount $StickTarget
On 11/7/18 1:52 PM, ToddAndMargo via users wrote:
On 11/5/18 10:03 PM, Paul Allen Newell wrote:
ToddAndMargo:
I am struggling with this one as well. To the best of my googling, it seems that the "sync" command needs to be done before clicking "safely remove" (or whatever). Documentation also says that "sudo umount <stick>" should do it, but I have experienced at least one instance where it didn't seem like it worked ... not certain what happened.
I am still testing but I "think" I am seeing that doing a "safely remove" and then a sync before physically removing gives best result (as in no pop-up warning). Do not understand why this is.
Not happy that the led light is vanishing on newer sticks ...
The "sync" command does not appear to be all that nice to the stick and there doesn't appear to be any way to isolate the "sync" to the stick.
I would hope that someone on this user-list who is more knowledgeable will correct me with a better way.
Best, Paul
On 11/05/2018 09:03 PM, ToddAndMargo via users wrote:
Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
This is the dismount part of my script:
sync; sync umount $StickTarget
You could do
sync -f $StickTarget;sync -f $StickTarget umount $StickTarget
to only sync the USB stick. I'm not sure your really need the second sync. IIRC you need to "sync;sync" before shutdown in case there's something being written to a system directory behind the scenes. In your situation with a specific stick, I don't think that's the case. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - If you're not part of the solution, you're part of the precipitate - ----------------------------------------------------------------------
On 11/8/18 6:52 AM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTarget
Calling sync twice?
Must be an "old" person. It was common practice back in the early 1980's to call sync twice before shutdown on Solaris. Don't ask me why. I was just "done that way".
On 11/7/18 3:04 PM, Ed Greshko wrote:
On 11/8/18 6:52 AM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTarget
Calling sync twice?
Must be an "old" person. It was common practice back in the early 1980's to call sync twice before shutdown on Solaris. Don't ask me why. I was just "done that way".
Yep, old person confirms.
~~R
"When you're a nail, every problem looks like a hammer." -- Anon.
On 11/07/2018 03:04 PM, Ed Greshko wrote:
On 11/8/18 6:52 AM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTarget
Calling sync twice?
Must be an "old" person. It was common practice back in the early 1980's to call sync twice before shutdown on Solaris. Don't ask me why. I was just "done that way".
Okay. I remember enough "don't ask, just do it this way" techniques from old days that I am certainly prepared to buy this one
On 11/7/18 4:06 PM, Paul Allen Newell wrote:
On 11/07/2018 03:04 PM, Ed Greshko wrote:
On 11/8/18 6:52 AM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTarget
Calling sync twice?
Must be an "old" person. It was common practice back in the early 1980's to call sync twice before shutdown on Solaris. Don't ask me why. I was just "done that way".
Okay. I remember enough "don't ask, just do it this way" techniques from old days that I am certainly prepared to buy this one
Again, I believe it was to ensure any background tasks writing to system volumes were "done". The typical command was
sync;sync;shutdown -h now
or (if you're as ancient as I am)
sync;sync;init 0 ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - grep me no patterns and I'll tell you no lines - ----------------------------------------------------------------------
On 11/07/2018 04:20 PM, Rick Stevens wrote:
On 11/7/18 4:06 PM, Paul Allen Newell wrote:
On 11/07/2018 03:04 PM, Ed Greshko wrote:
On 11/8/18 6:52 AM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTarget
Calling sync twice?
Must be an "old" person. It was common practice back in the early 1980's to call sync twice before shutdown on Solaris. Don't ask me why. I was just "done that way".
Okay. I remember enough "don't ask, just do it this way" techniques from old days that I am certainly prepared to buy this one
Again, I believe it was to ensure any background tasks writing to system volumes were "done". The typical command was
sync;sync;shutdown -h now
or (if you're as ancient as I am)
sync;sync;init 0
- Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
-grep me no patterns and I'll tell you no lines -
Rick:
Thread hopelessly out-of-sync on my end so I apologize if replies come out of order (do not understand what the cause is but am suspecting at least part of it is on my end)
Given that I have the same "ancient issue", I am surprised I don't remember this one as I searched online and there are a bunch of references to it. But I do have a memory of having to do song-and-dance regarding shutting down ... jsut can't remember the eact song or dance
Paul
On Thu, Nov 08, 2018 at 12:20:02AM +0000, Rick Stevens wrote:
On 11/7/18 4:06 PM, Paul Allen Newell wrote:
On 11/07/2018 03:04 PM, Ed Greshko wrote:
On 11/8/18 6:52 AM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTarget
Calling sync twice?
Must be an "old" person. It was common practice back in the early 1980's to call sync twice before shutdown on Solaris. Don't ask me why. I was just "done that way".
Okay. I remember enough "don't ask, just do it this way" techniques from old days that I am certainly prepared to buy this one
Again, I believe it was to ensure any background tasks writing to system volumes were "done". The typical command was
sync;sync;shutdown -h now
or (if you're as ancient as I am)
sync;sync;init 0
In UNIX, old Linux, and I think POSIX, sync merely queues things to be written. It does not guarentee the data are written. The multiple syncs were to provide time for the writes to complete.
From the current sync manpage, Linux's sync(2) does not return until the writes are done.
Maybe a second or more sync's would pick up any data modified while the first sync runs.
Jon
On Wed, Nov 7, 2018 at 8:03 PM Paul Allen Newell pnewell0705@gmail.com wrote:
On 11/07/2018 03:04 PM, Ed Greshko wrote:
On 11/8/18 6:52 AM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTargetCalling sync twice?
Must be an "old" person. It was common practice back in the early
1980's to call sync
twice before shutdown on Solaris. Don't ask me why. I was just "done that way".
Okay. I remember enough "don't ask, just do it this way" techniques from old days that I am certainly prepared to buy this one
old brain remembers ... sync; sync; sync;
Supposedly, #1 for the data blocks, #2 to ensure the updated inodes got written, #3 to ensure that superblock updates got written (if necessary).
On 11/07/2018 05:08 PM, Fulko Hew wrote:
On Wed, Nov 7, 2018 at 8:03 PM Paul Allen Newell <pnewell0705@gmail.com mailto:pnewell0705@gmail.com> wrote:
On 11/07/2018 03:04 PM, Ed Greshko wrote: > On 11/8/18 6:52 AM, Paul Allen Newell wrote: >> >> On 11/07/2018 01:52 PM, ToddAndMargo via users wrote: >>> >>> This is the dismount part of my script: >>> >>> sync; sync >>> umount $StickTarget >>> >>> >> Calling sync twice? > Must be an "old" person. It was common practice back in the early 1980's to call sync > twice before shutdown on Solaris. > Don't ask me why. I was just "done that way". > Okay. I remember enough "don't ask, just do it this way" techniques from old days that I am certainly prepared to buy this oneold brain remembers ... sync; sync; sync;
Supposedly, #1 for the data blocks, #2 to ensure the updated inodes got written, #3 to ensure that superblock updates got written (if necessary).
Does this turn into "I'll see your three syncs and raise you a fourth"?
On 11/07/2018 06:12 PM, Paul Allen Newell wrote:
On 11/07/2018 05:08 PM, Fulko Hew wrote:
On Wed, Nov 7, 2018 at 8:03 PM Paul Allen Newell <pnewell0705@gmail.com mailto:pnewell0705@gmail.com> wrote:
On 11/07/2018 03:04 PM, Ed Greshko wrote: > On 11/8/18 6:52 AM, Paul Allen Newell wrote: >> >> On 11/07/2018 01:52 PM, ToddAndMargo via users wrote: >>> >>> This is the dismount part of my script: >>> >>> sync; sync >>> umount $StickTarget >>> >>> >> Calling sync twice? > Must be an "old" person. It was common practice back in the early 1980's to call sync > twice before shutdown on Solaris. > Don't ask me why. I was just "done that way". > Okay. I remember enough "don't ask, just do it this way" techniques from old days that I am certainly prepared to buy this oneold brain remembers ... sync; sync; sync;
Supposedly, #1 for the data blocks, #2 to ensure the updated inodes got written, #3 to ensure that superblock updates got written (if necessary).
Does this turn into "I'll see your three syncs and raise you a fourth"?
Only as long as you don't rape Thrace thrice.
On Wed, Nov 07, 2018 at 08:08:41PM -0500, Fulko Hew wrote:
old brain remembers ... sync; sync; sync;
Yep, that was the mantra.
Supposedly, #1 for the data blocks, #2 to ensure the updated inodes got written, #3 to ensure that superblock updates got written (if necessary).
Well, that wasn't so. I was doing Unix internals at Bell Labs in 1980. Sync flushed all pending disk I/O operations for the entire kernel ...that's all processes and *all users* on a multi-user machine. The idea was apparently that multiple "syncs" would assure flushing operations that would get submitted; even then it was a bit of apocrypha.
However, the early days *were* interesting; BTL was pushing Unix hard by 1980, especially for the 5ESS project, and more people than had ever been using a Unix system concurrently were on the development systems.
One week started out badly for us; for some reason everyone was experiencing *incredibly* poor performance. We figured out that we were all on the same server, but the poor guys in the data center couldn't see anything wrong; it was just, suddenly, and inexplicably ***slow***.
I was chatting with a new hire who'd started that morning, and he proudly showed me a vi macro he'd written to "guarantee that he never lost data". Really? Let's see...hmm...every command issued was intercepted...AND CALLED SYNC. On a machine hosting a boatload of other users. He was calling sync for every single editor command he typed.
Cluebat applied, macro removed, life returned to normal.
(And no, I don't know when they stopped letting a single user do that to the whole system, and lost access to Unix source when I left the Labs Way Back When, but they *must* have, right? And no, I've not cared enough to go see how Linux does it.)
Cheers, -- Dave Ihnat dihnat@dminet.com
On 11/7/18 5:52 PM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTarget
Calling sync twice?
Dates back at least (in my memory) to VAX 11/750, BSD 4.2 days.
On Wed, 2018-11-07 at 18:53 -0500, Tim Evans wrote:
On 11/7/18 5:52 PM, Paul Allen Newell wrote:
On 11/07/2018 01:52 PM, ToddAndMargo via users wrote:
This is the dismount part of my script:
sync; sync umount $StickTargetCalling sync twice?
Dates back at least (in my memory) to VAX 11/750, BSD 4.2 days.
I see your BSD 4.2 and raise you PDP-11/45, 5th Edition UNIX (nb: *not* System V).
poc
On 11/5/18 9:03 PM, ToddAndMargo via users wrote:
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
When the umount is complete, it is safe to remove.
On 11/7/18 3:58 PM, Samuel Sieb wrote:
On 11/5/18 9:03 PM, ToddAndMargo via users wrote:
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
When the umount is complete, it is safe to remove.
Not with the led light flashing!!!!
On 11/7/18 4:24 PM, ToddAndMargo via users wrote:
On 11/7/18 3:58 PM, Samuel Sieb wrote:
On 11/5/18 9:03 PM, ToddAndMargo via users wrote:
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
When the umount is complete, it is safe to remove.
Not with the led light flashing!!!!
If the LED is still flashing then it's the stick having a delay before turning it off or some other USB bus activity. When the umount returns, everything is flushed. I guarantee that when Gnome says you can remove the stick, it's because the umount call returned. Do a Google search for "does umount sync" and see https://groups.google.com/forum/#!topic/comp.os.linux.development.apps/8QDlM... for your specific question.
On 11/7/18 4:33 PM, Samuel Sieb wrote:
On 11/7/18 4:24 PM, ToddAndMargo via users wrote:
On 11/7/18 3:58 PM, Samuel Sieb wrote:
On 11/5/18 9:03 PM, ToddAndMargo via users wrote:
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
When the umount is complete, it is safe to remove.
Not with the led light flashing!!!!
If the LED is still flashing then it's the stick having a delay before turning it off or some other USB bus activity. When the umount returns, everything is flushed. I guarantee that when Gnome says you can remove the stick, it's because the umount call returned. Do a Google search for "does umount sync" and see https://groups.google.com/forum/#!topic/comp.os.linux.development.apps/8QDlM... for your specific question.
You bet.
Only problem is that when the light is blinking, there is still something being transferred.
On 11/5/18 9:03 PM, ToddAndMargo via users wrote:
Hi All,
I am starting to use flash drive s with no led activity indicator. In my scripts that write to them, I am able to umount then watch the blinking lights to make sure it is done before removing them
But with no led indicator, how can I test from my script to make sure it is done writing?
Many thanks, -T
A guy over on comp.os.linux.misc told me to issue "sync" after the umount, as it wont complete until syncing is done.
Don't know if it will work as there is no led on these sticks.
-
Dave Ihnat -
Ed Greshko -
Fulko Hew -
George Avrunin -
Joe Zeff -
Joerg Lechner -
Jon LaBadie -
Patrick O'Callaghan -
Paul Allen Newell -
Richard England -
Rick Stevens -
Samuel Sieb -
Tim Evans -
ToddAndMargo