R
Rod Speed
Few seconds of no led activity and the Win transfer window gone.
<reams of your puerile shit any 2 year old could leave for dead flushed where it belongs>
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Few seconds of no led activity and the Win transfer window gone.
<reams of your puerile shit any 2 year old could leave for dead flushed where it belongs>
R
Rod Speed
kony wrote
You never ever could bullshit your way out of a wet paper bag.
I said THAT SYSTEM never does that, ****wit.
With a pending write operation, do tell us what is going to
make the OS think to itself "I'll just wait until someone
tells me to write this a 2nd time as the first was just an
idea not a command", instead of doing it at next available
opportunity just as if you use Safely Remove feature?
You never ever could bullshit your way out of a wet paper bag.
It can keep stating that,
I said THAT SYSTEM never does that, ****wit.
R
Rod Speed
kony wrote
You're lying, as always, when you get done like a dinner, as always.
THAT SYSTEM I made that comment about, ****wit.
You'll end up completely blind if you dont watch out, child.
You'll end up completely blind if you dont watch out, child.
Haha, thank you for conceding I am right.
You're lying, as always, when you get done like a dinner, as always.
Then what are you referring to?
THAT SYSTEM I made that comment about, ****wit.
A hypothetical system that never does?
Nope.
lol, if that is the case, then by definition your hypothetical
system meets that, but since it is a dream rather than a
constant, we can ignore it as something to assume.
You'll end up completely blind if you dont watch out, child.
In an ideal world you would be right, that's how things
ought to work. In the real world, apps misbehave and
windows doesn't provide the level of checks and balances
needed... and why would it, there is no competitive reason
they would need to do so.
That's why monopolies are bad, simple things like this go unresolved for years.
You'll end up completely blind if you dont watch out, child.
A
Arno
[/QUOTE]In comp.sys.ibm.pc.hardware.storage kony said:Windows will tell you that it is safe to remove the drive only
after it has a) written all buffered data and b) blocked the
device so no new writes can happen. In the absence of a programming
error, this is reliable.
^ That last sentence is the key... of course windows has
never had programming errors and never will, they're design
/features/.
Ok, let me re-phrase that ;-)
If MS has not (again) messed up functionality that is important
and works reliable on real OSes, then safe removal on Windoes
is indeed safe.
Short form: Don't use Windows unless you have to. It sucks.
The question we are discussing here does not even come
up with proper OSes.
Arno
A
Arno
In comp.sys.ibm.pc.hardware.storage kony said:On Thu, 19 Nov 2009 04:19:44 +1100, "Rod Speed"
With a pending write operation, do tell us what is going to
make the OS think to itself "I'll just wait until someone
tells me to write this a 2nd time as the first was just an
idea not a command", instead of doing it at next available
opportunity just as if you use Safely Remove feature?
Actually the way this goes ios something like this:
1) The OS waits until it reaches the soft flush timeout.
The intention is to get larger writes.
It then starts to write with relative low priority.
It may also start before if the I/O load is low.
2) Then data in the buffer reaches a certain age
(the hard flush timeout), then the data is written to
disk with high priority and very little other things get
done. Data written in this mode to a different disk can
still cause delays.
The longer delay 1) does give significant performance
improvement. Historically, it used to be as high as 5 minutes,
and is more in the 1 minute range now.
With an "optimize for fast removal", the hard flush timeout
is set to zero or a very low value (1 sec). An alternative
is a "sync" mount, were data is flushed immediately, but
that has massive negative impact on performance (e.g.
100-1000 times slower). It is the only way to ensure data
is on disk before the write system call returns to the
application. Even with a sync mount, writing can take some
time. Due to its low performance, a sync mount is possibly
less safe for the purpose at hand.
What happens on umount (safe removal, why does MS has to
invent their own language for well established things??)
is that the hard flush timeout is set to zero for the
affectyed device and the buffer is monitred until there
are no more pending writes for the device. In addition the
device is removed from visibility for the applications.
This may fail if some applications have open files. The
failure is the correct bbehaviour here, a forced close on
open files usually causes data corruption.
When done, the "you may now unplug" message is displayed.
Arno
A
Arno
In comp.sys.ibm.pc.hardware.storage kony said:On Thu, 19 Nov 2009 09:13:11 +1100, "Rod Speed"
Haha, thank you for conceding I am right. For those not
acquainted with Rod Speed jargon, google groups will bring
you up to /rod/ speed.
Then what are you referring to? A hypothetical system that
never does? lol, if that is the case, then by definition
your hypothetical system meets that, but since it is a dream
rather than a constant, we can ignore it as something to
assume.
In an ideal world you would be right, that's how things
ought to work. In the real world, apps misbehave and
windows doesn't provide the level of checks and balances
needed... and why would it, there is no competitive reason
they would need to do so.
That's why monopolies are bad, simple things like this go
unresolved for years.
Indeed. That is also why MS is so keen on maintaining its
monopoly. They know thay cannot compete on technological
merit. It is incredible how far they are behind in some
areas.
Arno
E
Eddie
Actually the way this goes ios something like this: 1) The OS
waits until it reaches the soft flush timeout.
The intention is to get larger writes. It then starts to
write with relative low priority. It may also start before
if the I/O load is low.
2) Then data in the buffer reaches a certain age
(the hard flush timeout), then the data is written to disk
with high priority and very little other things get done.
Data written in this mode to a different disk can still
cause delays.
The longer delay 1) does give significant performance
improvement. Historically, it used to be as high as 5 minutes,
and is more in the 1 minute range now.
With an "optimize for fast removal", the hard flush timeout is
set to zero or a very low value (1 sec). An alternative is a
"sync" mount, were data is flushed immediately, but that has
massive negative impact on performance (e.g. 100-1000 times
slower). It is the only way to ensure data is on disk before
the write system call returns to the application. Even with a
sync mount, writing can take some time. Due to its low
performance, a sync mount is possibly less safe for the purpose
at hand.
What happens on umount (safe removal, why does MS has to invent
their own language for well established things??) is that the
hard flush timeout is set to zero for the affectyed device and
the buffer is monitred until there are no more pending writes
for the device. In addition the device is removed from
visibility for the applications. This may fail if some
applications have open files. The failure is the correct
bbehaviour here, a forced close on open files usually causes
data corruption.
When done, the "you may now unplug" message is displayed.
Arno
Really good info. Thank you. Where's it from? It explains background
to some things already posted and shows some previous info hasn't
been 100% right.
Eg. wait a few secs after LED stops.
Eg. need to close apps for Safe Removal to succeed.
Eg. ...
A
Arno
[/QUOTE]In comp.sys.ibm.pc.hardware.storage Eddie said:Actually the way this goes ios something like this: 1) The OS
waits until it reaches the soft flush timeout.
The intention is to get larger writes. It then starts to
write with relative low priority. It may also start before
if the I/O load is low.
2) Then data in the buffer reaches a certain age
(the hard flush timeout), then the data is written to disk
with high priority and very little other things get done.
Data written in this mode to a different disk can still
cause delays.
The longer delay 1) does give significant performance
improvement. Historically, it used to be as high as 5 minutes,
and is more in the 1 minute range now.
With an "optimize for fast removal", the hard flush timeout is
set to zero or a very low value (1 sec). An alternative is a
"sync" mount, were data is flushed immediately, but that has
massive negative impact on performance (e.g. 100-1000 times
slower). It is the only way to ensure data is on disk before
the write system call returns to the application. Even with a
sync mount, writing can take some time. Due to its low
performance, a sync mount is possibly less safe for the purpose
at hand.
What happens on umount (safe removal, why does MS has to invent
their own language for well established things??) is that the
hard flush timeout is set to zero for the affectyed device and
the buffer is monitred until there are no more pending writes
for the device. In addition the device is removed from
visibility for the applications. This may fail if some
applications have open files. The failure is the correct
bbehaviour here, a forced close on open files usually causes
data corruption.
When done, the "you may now unplug" message is displayed.
Arno
Really good info. Thank you. Where's it from? It explains background
to some things already posted and shows some previous info hasn't
been 100% right.
Well, basically from my academic OS design course (I was
listener not lecturer, not exactly my field) and from wanting
to find out way back. It is an important topic in OS design, so
a current book on the topic should have one or several
chapters on this.
One problem with Windows is that they do not follow established
ways to do this. In Unix, e.g., you always have to explicetly
tell the OS to release a storage medium and to make the potential
damage of unexpected removal small, journalling filesystems are
used.
Arno
N
Nart
Arno said:Indeed. That is also why MS is so keen on maintaining its monopoly.
There is no monopoly, the main alternative is quite literally free.
G
GT
Rod Speed said:David Brown wrote
Irrelevant to your stupid /always/ claim.
Not in the real world.
In the real world that the rest of us live in, it will take longer to write
more data to a USB flash drive than it would to write less information.
Unless you can guarantee that the data write has finished then for peace of
mind, you should *always* use the safe removal option. If the USB stick has
an LED and you can see that the write activity has stopped and the OS is not
busy doing something else, then you can pull it out. If the USB stick has no
LED, then you will not know for sure whether the OS has finished writing to
it or not. If you are content with crossing your fingers and hoping that 'a
while' has passed, then you can follow Rod's advice and just pull the USB
stick out.
Telling us that the length of time the OS needs to write to the USB stick is
'a while', but then telling us that the time is irrelevant is really not
helpful!
R
Rod Speed
GT wrote
That was a comment on the second and third bits, not the first which was too obvious to comment on.
Wrong when you check whats happened with the copy popup and the led on the stick.
What I said in different words.
Wrong. You can check the popup on that.
Or you can have enough of a clue to use the led and the popup.
Your mindless pig ignorant shit in spades.
In the real world that the rest of us live in, it will take longer to write more data to a USB flash drive than it
would to write less information.
That was a comment on the second and third bits, not the first which was too obvious to comment on.
Unless you can guarantee that the data write has finished then for
peace of mind, you should *always* use the safe removal option.
Wrong when you check whats happened with the copy popup and the led on the stick.
If the USB stick has an LED and you can see that the write activity has stopped and the OS is not busy doing something
else, then you can pull it out.
What I said in different words.
If the USB stick has no LED, then you will not know for
sure whether the OS has finished writing to it or not.
Wrong. You can check the popup on that.
If you are content with crossing your fingers and hoping that 'a while' has
passed, then you can follow Rod's advice and just pull the USB stick out.
Or you can have enough of a clue to use the led and the popup.
Telling us that the length of time the OS needs to write to the USB stick is 'a while', but then telling us that the
time is irrelevant is really not helpful!
Your mindless pig ignorant shit in spades.
T
Tim Mastrogiacomo
I've been removing the drive immediately (all drives: USB, SD,
external HDD, ect) for years now and I've never had a problem. Course
I ways wait to remove it until a few moments after the lights stop
flashing.
Same here.
Tim Mastrogiacomo
T
TVeblen
Eddie said:Do I always need to close or stop a USB flash drive before I remove
it?
I'm using XP. In XP's Device Manager there is an entry for Disk
Drives and when I look at the Policies tab for the flash drive, it
says:
"Optimized For Quick Removal. This setting enables
write caching on the disk and in Windows, so you can
disconnect this device without using the Safe Removal
icon."
My friends get upset if I don't use the Safe Removal process when
their USB memory is in my PC. Maybe they're repeating a mistake? Or
is there a reason which I'm missing that says I should always use
Safe Removal?
This is a toilet seat issue! There are logical reasons why you shouldn't
need to put the seat down, but if you want your honey to be nice to you, you
do it. Only an idiot would fight that fight! Use safe removal for your
friends and make crude comments as you do it to entertain yourself and ease
the "pain". But then that's another thorny office issue too, ain't it?
D
David Brown
Once a post has triggered a "rodbot" reply, you just have to ignore any
posts by Rod in that branch - you'll never get an intelligible response
from him. Pick a different branch and make the same comment or ask the
same question, and you might well get a helpful answer.
Another thing to remember here is that while the LED going out or the
"copy box" closing will indicate the end of that particular write, you
don't necessarily know that there will be no more writes. If all you
are doing is putting the stick in, copying files, then taking it out,
then you know what's going on. But if you are using the stick directly,
and have applications opening files on the disk, then there may be other
things going on. For example, MS Word likes to make hidden temporary
files in the same directory as the original data file. It will do no
harm if these files get lost or corrupted during an unsafe removal, but
you also risk messing up the FAT or directories with corrupted writes.
Just because the LED has gone out, does not guarantee that it won't come
on again just as you are pulling it out!
posts by Rod in that branch - you'll never get an intelligible response
from him. Pick a different branch and make the same comment or ask the
same question, and you might well get a helpful answer.
In the real world that the rest of us live in, it will take longer to write
more data to a USB flash drive than it would to write less information.
Unless you can guarantee that the data write has finished then for peace of
mind, you should *always* use the safe removal option. If the USB stick has
an LED and you can see that the write activity has stopped and the OS is not
busy doing something else, then you can pull it out. If the USB stick has no
LED, then you will not know for sure whether the OS has finished writing to
it or not. If you are content with crossing your fingers and hoping that 'a
while' has passed, then you can follow Rod's advice and just pull the USB
stick out.
Another thing to remember here is that while the LED going out or the
"copy box" closing will indicate the end of that particular write, you
don't necessarily know that there will be no more writes. If all you
are doing is putting the stick in, copying files, then taking it out,
then you know what's going on. But if you are using the stick directly,
and have applications opening files on the disk, then there may be other
things going on. For example, MS Word likes to make hidden temporary
files in the same directory as the original data file. It will do no
harm if these files get lost or corrupted during an unsafe removal, but
you also risk messing up the FAT or directories with corrupted writes.
Just because the LED has gone out, does not guarantee that it won't come
on again just as you are pulling it out!
A
Arno
In comp.sys.ibm.pc.hardware.storage kony said:On Thu, 19 Nov 2009 03:28:05 -0500, Eddie
Except you can clearly see windows behavior yourself and
didn't read (or I didn't express well enough) that those who
want not to have to use Safely Remove will have left the
optimize for safe removal default setting as-is.
If you leave the default "optimize for quick removal" for
the flash drive, you will never have to wait even 1/4th a
minute after the LED stops, the "few seconds" isn't even
needed but to make sure you are seeing it stopped in case
you misrecall the LED activity patterns between multiple
different drives.
Those of us who routinely use flash drives without using
safely remove feature realize this. Try it yourself, on a
test if you doubt it rather than only backup up important
data.
The effort people will use to justify their risky
behaviour is astonishing. It does not make the behaviour
any less risky or the justification true.
Arno
P
Pen
All too true. What is truly amazing is that when it is pointed out to themArno said:The effort people will use to justify their risky
behaviour is astonishing. It does not make the behaviour
any less risky or the justification true.
Arno
they get defensive and refuse to even listen to why it's risky
and maybe they should consider paying attention to safe practices until they
have their second or third disaster. Then they come back here whining about
the unreliability of the equipment.
G
GT
[snip] - no need to see the rest of this, Rod has reduced things to a
slanging match. I love a good virtual argument!
I think you will find it impossible to shit 'in' spades as a spade is a flat
metallic gardening implement. Perhaps you meant shit 'on' spades? Please
check your post before committing! A couple of 8 letter words though - well
done - obviously didn't learn those from your mamma!
slanging match. I love a good virtual argument!
Your mindless pig ignorant shit in spades.
I think you will find it impossible to shit 'in' spades as a spade is a flat
metallic gardening implement. Perhaps you meant shit 'on' spades? Please
check your post before committing! A couple of 8 letter words though - well
done - obviously didn't learn those from your mamma!
T
TVeblen
Eddie said:Do I always need to close or stop a USB flash drive before I remove
it?
I'm using XP. In XP's Device Manager there is an entry for Disk
Drives and when I look at the Policies tab for the flash drive, it
says:
"Optimized For Quick Removal. This setting enables
write caching on the disk and in Windows, so you can
disconnect this device without using the Safe Removal
icon."
My friends get upset if I don't use the Safe Removal process when
their USB memory is in my PC. Maybe they're repeating a mistake? Or
is there a reason which I'm missing that says I should always use
Safe Removal?
See: http://www.venukb.com/2008/06/11/safely-remove-usb-hardware/
R
Rod Speed
David Brown wrote
Never ever could bullshit and lie its way outof a wet paper bag.
It does if you wait a few seconds after it goes out, fool.
GT wrote
Once a post has triggered a "rodbot" reply, you just have to ignore
any posts by Rod in that branch - you'll never get an intelligible
response from him. Pick a different branch and make the same comment
or ask the same question, and you might well get a helpful answer.
Never ever could bullshit and lie its way outof a wet paper bag.
Another thing to remember here is that while the LED going out or the
"copy box" closing will indicate the end of that particular write, you
don't necessarily know that there will be no more writes. If all you
are doing is putting the stick in, copying files, then taking it out,
then you know what's going on. But if you are using the stick
directly, and have applications opening files on the disk, then there
may be other things going on. For example, MS Word likes to make
hidden temporary files in the same directory as the original data
file. It will do no harm if these files get lost or corrupted during
an unsafe removal, but you also risk messing up the FAT or
directories with corrupted writes. Just because the LED has gone out,
does not guarantee that it won't come on again just as you are pulling it out!
It does if you wait a few seconds after it goes out, fool.
R
Rod Speed
Some gutless ****wit desperately cowering behind
GT desperately attempted to bullshit and lie its way out of
its predicament and fooled absolutely no one at all, as always.
GT desperately attempted to bullshit and lie its way out of
its predicament and fooled absolutely no one at all, as always.