|
Completely unexpected on my part, had to go off on a research project - wtf is UEFI (or whatever). All sorts of contradictory answers, and of course, Microsoft folks chime in with "you'll just need to re-install Windows". Uh not happening....
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
This might help. UEFI can boot from either MBR or GPT partitions but BIOS can only do MBR (I think).
UEFI and partition types
|
|
|
|
|
When I swapped to an M.2 SSD, I installed W10 over the course of a commercial break.
3 minutes from cold boot to interactive use on a new install; SATA-based can't even come close to that.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Linux is even faster. I have a full ubuntu install on a laptop with a nVME drive, and from power-on to login prompt, it boots in about 30 seconds (even faster if the USB drive is plugged in, because grub insists on looking for it for at least 10 seconds before it times out and continues the boot process.
On another machine, I'm running a minimal Lubuntu (also on a nVME) - less than 10 seconds on that one.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
You misunderstand. I installed windows in that time frame.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
I agree. I have an m.2, 4x pcie SSD and it benchmarks three times faster than a SATA SSD on the same computer.
|
|
|
|
|
Scary how dang fast the pcie drives are...
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
My backup strategy is pretty simple: Invoking Robocopy from a small PowerShell script that works out the logic of identifying the backup drive, as its letter might not always be the exact same depending on what else I might happen to have hooked up. I like Robocopy because it's as simple as a recursive "copy star-dot-star", and it automatically skips anything that hasn't changed. Also, having a straight copy of the file system means I have direct access to any file, without relying on some BLOB that can only be accessed by some proprietary backup software that has to be installed on whatever system I hook up the backup drive to.
In any case…I have 2 backup drives (normally, one offline, sitting next to the computer, and the other at the office for monthly rotation). Both are in external USB enclosures. Both have started exhibiting the same problem where the machine would stop reading (writing?) at the same point on the same file (some large-ish file, but otherwise totally random in the sense that there’s nothing that sets it apart from plenty of others). CPU activity settles down to nothing, same with disk reads/writes, then I can’t kill Robocopy with Ctrl-C or kill the PowerShell session with Task Manager. Logging out/rebooting can’t “cleanly” terminate the process either, as it just sits there forever (I've let it run overnight) and I have to hard-reset the system. Or, yank out the USB cable--then the system comes back to life immediately. Not good—I fully expect this sort of thing to eventually result in corrupt files/file systems if I have to keep doing this.
After rebooting (or re-inserting the USB cable), if I restart the same copy operation, it may manage to proceed further, or get stuck at the same point on the same file again. With enough retries, I suppose I could complete the full backup eventually, but obviously that’s not the way to go.
Copying the offending file with Explorer to the backup drive again results in the same thing – it eventually just stops (doesn’t complain about any read/write error, just no further progress is made).
Everything at this point is suggesting a bad source file. But if I move the file elsewhere or delete it altogether, then the same thing happens again with the next large-ish file it might encounter. Or it might not.
I ran chkdsk /f on the source and both target drives. No problem whatsoever. I don't know how thorough chkdsk is, but it claims everything is squeaky clean.
The crazy solution? Hook up the backup drive to another system, and run the backup through a share across the LAN, instead of directly from local (internal) drive to local (USB) drive. Then all files can be read and the full backup completes without even a hint of any sort of slowdown at any point.
Since I'm copying across the LAN with the same USB cable, the only thing I have left to blame is the source computer's USB port. There's only one at the front, and the ones at the back are unfortunately rather difficult to reach (it's a lousy physical setup), but I'll have to try that just to confirm.
In the meantime...if I get the same thing through another port...what else is left I should I be looking for?
(and yes, the anti-virus remains completely quiet)
|
|
|
|
|
|
Any backup software that creates a large file that can only be opened by said software is a non-starter in my book.
|
|
|
|
|
"There can only be one!" 
I'm afraid that's the way most backup programs work ...
|
|
|
|
|
...and that's why I don't use any of 'em.
|
|
|
|
|
1. perhaps there is an error. Default in Robocopy:
/R:n :: number of Retries on failed copies: default 1 million.
/W:n :: Wait time between retries: default is 30 seconds.
Try /R:zero (use 0, it gave me a happy face)
maybe you tried this already?
2. File or directory size greater than 4GB?
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
My script invokes Robocopy with
/MIR /R:0
My backup set includes files that are tens of GBs in size, and I haven't seen any problem with those. I suppose I shouldn't have said that it only happens with large files, but rather, that I haven't seen it happen with small files.
|
|
|
|
|
The solution kinda makes me wonder if it's a memory fault, rather than a disk / usb problem.
What happens if you try copying a large file repeatedly onto the same disk? A quick Powershell - logging each time it completed each copy so you can see any slowdown - and leave it running overnight?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: The solution kinda makes me wonder if it's a memory fault, rather than a disk / usb problem.
Even if--for a given file--it either doesn't happen at all, or always happens at the same place, even after many reboots? :-/
OriginalGriff wrote: What happens if you try copying a large file repeatedly onto the same disk? A quick Powershell - logging each time it completed each copy so you can see any slowdown - and leave it running overnight?
I'm tempted to run sdelete from SysInternals and have it fill all free space to see what happens. But that's a good idea as well. I'll follow up if I go ahead with it.
|
|
|
|
|
Have you looked in the Event Log for any hardware errors. Does sound to me like it's the USB in your computer.
|
|
|
|
|
Rather thoroughly, yeah. I can see the events complaining about the unexpected reboots (of my own creation), but nothing about hardware faults, unfortunately.
|
|
|
|
|
I use EaseUs Todo Backup. It puts the files in a ".pdb" blob that can be opened by Windows Explorer. You don't need the backup s/w to open it and extract files.
|
|
|
|
|
matblue25 wrote: I use EaseUs Todo Backup. It puts the files in a ".pdb" blob that can be opened by Windows Explorer.
Really? Windows Explorer natively understands these BLOBs created by a third-party program, so a machine that's never had it installed on it before will understand these file types? I find that dubious, because I just created an empty .pdb file, and Explorer showed a generic icon and set the type to "PDB file", which tells me it's an unregistered file type and Windows wouldn't know what to do with it.
|
|
|
|
|
You're right. If I double click on a pdb file (created by EaseUs) on a computer that has EaseUs installed on it, it opens in Windows Explorer. But if I try it on another computer that doesn't have EaseUs installed, it won't open it. It really is Explorer opening the file, not the EaseUs app. I looked in the registry for what kind of magic it could be doing to make that happen but didn't see how it's done. Whatever it is, it's not the standard HKEY_CLASSES_ROOT\.pdf registry key. Must be some kind of extension added to Explorer. Sorry if I got your hopes up.
|
|
|
|
|
matblue25 wrote: Must be some kind of extension added to Explorer. Sorry if I got your hopes up.
Of course it's an extension. And no, I didn't have one iota of "hope" this would even be possible without said third-party software.
I still prefer having a plain copy of the individual files--nothing will change that. That way, anything that can read NTFS will be able to read my backup. One less thing that can go wrong, really. Just how resilient is EaseUs to corruption in its own files?
|
|
|
|
|
I haven’t had any problems with it yet. My wife is constantly losing files and I’ve been able to recover them all so far. Just had to reload my C: drive from backup because it wouldn’t boot (after several attempts to fix it). It restored and booted right away. Just one issue minor issue with Windows that I had to fix after the restore, which I can’t blame on EaseUs.
|
|
|
|
|
I would get a new sourcedrive immediately. It has bad sectors.
Unless it's an SSD of course.
|
|
|
|
|
What do you make of the part where, if I copy from that same source drive across my LAN instead of locally, there's no error or even any sort of slowdown whatsoever?
If the source drive had bad sectors, then I don't see how copying across the LAN would change anything.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
