-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to continue a move if you hit ENTER instead of type CONTINUE? #23
Comments
I think I've managed to get things going again:
Disks are whirring away - so that's a good sign. I would really feel better if the default of ENTER to ABORT would be changed to just loop and accept either Ctrl + C or CONTINUE.... |
You solved it by yourself :) About changing ENTER to simply display the prompt again instead of aborting: it's definitely useful, thanks for the idea |
Yep - almost there:
Yeah - that's why I didn't close this issue.... It's almost standard to do the "Is that terminal still alive? enter enter enter" type thing - if you're not aware in advance that an enter will abort on errors, this leads to a "Oh crap, now what do I do?" moment. I had this myself :) It took me ~45 minutes or so do hunt down the README.fsremap after I figured out what the fstransform script actually does and get it going again. Hopefully I've done it right... The figures it quotes seems to say so. I've just been careful not to hit enter - as I don't know if that will auto-ack an abort if there's an error either ;) |
I'm a little concerned with the results of this scan - going from XFS -> ext4, the final fsck after fsremap finished is showing quite a few errors:
This left me with ~1800 files in /lost+found. I'm guessing this isn't a good thing - and the hard part now is trying to figure out what those files even are. There were no errors in the fsck of the image file, nor the fsremap. |
What version of fstransform/fsremap are you using? |
I'm using the version in Fedora 30 - packaged as: fstransform-0.9.3-4.fc30.x86_64 Looks like it hasn't changed in a while:
I'll open up a bug report and get Fedora to update it. EDIT: Bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=1705564 |
Yes, thanks. |
Ok, I'll add this to the report (can't edit it). |
On the same topic of data corruption, is there a way to see what files got corrupted? I've found a few things that are dead - so far nothing important (yay) - but I'm not sure if I've found it all... |
First of all, sorry for the corruption. The corruption bug #13 works like this: if you have a very large contiguous area on disk to copy (larger than the RAM buffer), only an initial fragment equal to the RAM buffer size will be copied - the rest will be missing, i.e. whatever happens to be already on disk in the destination area will remain there instead of being written over. This happens at the block level, so large filesystem metadata blocks can get corrupted - thus the large number of fsck error. For files, it's not so common that two files are in consecutive blocks, but it may happen. |
All good - its a bit of a pain - but the majority at the moment have been backups of stuff that it doesn't really matter if it is dead or not - ie I just blow away that entire backup. My DVD collection is mostly mkv - so I'm using mkvmerge and setting its output to /dev/null to try and validate the bitstream throughout the file. That's pretty quick and seems to be a good detection for a corrupted file. I have nothing against trashing the corrupted ones - and if I can be bothered, re-ripping / encoding. I haven't started validating the software ISOs - but they're mostly stuff like the Windows 10 ISO which can be downloaded from MS again anyway - so again, no great loss - just a bit annoying. There's Fedora ISOs, RHEL ISOs etc - same deal - nothing a redownload won't fix. I did notice that a lot of photos backed up to that array seemed to survive - but the file was pretty much either empty, or with enough dead metadata that it couldn't decode. Checking with I did end up moving away from that ext4 RAID6 to md RAID6 + btrfs though - which was my end goal... XFS -> ext4 -> BTRFS - as the btrfs-convert didn't want to work either :\ I ended up just rsync'ing everything to a borrowed 6Tb disk, rehashing the array, then rsync'ing back. So now just want to try and find as much of the corrupt stuff as I can. |
So I left the fsmove process run for ~25 hours, it did its thing, but it complained that I removed an old file from that drive while the move was in progress. It was an old .fstransform file that I didn't let go very long (hence didn't successfully copy a single file - I checked by mounting it).
Upon completion of the fsmove, it errored with:
As I'd hit ENTER at some point in that terminal over the last 25 hours, it immediately quit.
I've mounted both the mount and loop mountpoints again, and I can confirm that all files except the excluded loop file have been moved to the loop filesystem.
So how to continue?
(and on another note, can we drop just a plain ENTER as being an ABORT?! especially if it may have been entered many, many hours prior and sat in a buffer since....
The text was updated successfully, but these errors were encountered: