I have migrated from unraid by formatting the parity drive to ext4 and leaving all my unraid disks on reiserfs file system. I am pooling with mhddfs.
I am using ubuntu desktop but have set it so that it doesnt automount disks and am using the fstab.
When I first ran a sync it came back with an error saying:
Error reading file '/mnt/disk1/Series/Russel Howards Good News/Russell Howard's Good News - 7x10 - Episode 10.mkv' at offset 358944768 for size 192512. Input/output error.
DANGER! Unexpected input/output read error in a data disk, it isn't possible to sync.
Ensure that disk '/mnt/disk1/' is sane and that file '/mnt/disk1/Series/Russel Howards Good News/Russell Howard's Good News - 7x10 - Episode 10.mkv' can be read
I decided that this was not a file I needed so i tried to delete it off the disk. When I tried to do this I got an error saying that disk 1 is a read-only file system.
I then rebooted the server and was able to delete the file.
I then ran the sync and had it finished successfully. I decided to run the sync again a day later to make sure all was good. Ended up with the same sync error with the same file!
So it would seem that the file is somehow coming back? Surely this does not happen with a sync? As I type now I am unable to delete the file again due to disk1 being read only. I am leaving the server in its current state and hoping for some help.
I was thinking about migrating all reiserfs to ext4 but I have a couple disks with bad sectors on it. Ubuntu is reporting the disks are ok. disk1 currently has no bad sectors. I dont want to start migrating until I am sure I have a valid sync.
So basically three questions.
Why does sync keep failing with the same file?
How does this file keep coming back after deletion?
Why is disk1 changing to a read only file system?
Thanks.
Last edit: molesza1 2015-02-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have a broken disk, making it read-only is standard kernel's way of dealing with it.
Stop any sync, get a new disk and recover either from the other disks+parity or try to copy as much as possible from the failing disk. Then, after you MAKE SURE you have EVERYTHING you need from the failed disk you can change snapraid to point to the new disk and sync again.
You can confirm the disk is broken with badblocks. But I advise not to stress the disk until you recovered first everything you wanted from there. In particular do not do any sync until you finished the recovery and double and triple checked you have all the data you want.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Normally you can test with badblocks but that will stress the drive a lot and I strongly recommend to avoid it for now if you still want the data from there.
Otherwise look in dmesg (either dmesg for current buffer or /var/log/dmesg for older events). I am sure it'll be full of all kinds of errors about this device and also there should be a message about making it read-only because of errors.
Once the device is bad you can't trust it, probably the delete operation (which is in fact just a write operation) failed, or the drive tried to relocate the sector to some other place and it failed, etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That all makes sense. Thanks VERY much for your help. I will diagnose when i get home tonight. Pity I dont have a hot spare! Will let you know how I get on. Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have migrated from unraid by formatting the parity drive to ext4 and leaving all my unraid disks on reiserfs file system. I am pooling with mhddfs.
I am using ubuntu desktop but have set it so that it doesnt automount disks and am using the fstab.
When I first ran a sync it came back with an error saying:
Error reading file '/mnt/disk1/Series/Russel Howards Good News/Russell Howard's Good News - 7x10 - Episode 10.mkv' at offset 358944768 for size 192512. Input/output error.
DANGER! Unexpected input/output read error in a data disk, it isn't possible to sync.
Ensure that disk '/mnt/disk1/' is sane and that file '/mnt/disk1/Series/Russel Howards Good News/Russell Howard's Good News - 7x10 - Episode 10.mkv' can be read
I decided that this was not a file I needed so i tried to delete it off the disk. When I tried to do this I got an error saying that disk 1 is a read-only file system.
I then rebooted the server and was able to delete the file.
I then ran the sync and had it finished successfully. I decided to run the sync again a day later to make sure all was good. Ended up with the same sync error with the same file!
So it would seem that the file is somehow coming back? Surely this does not happen with a sync? As I type now I am unable to delete the file again due to disk1 being read only. I am leaving the server in its current state and hoping for some help.
I was thinking about migrating all reiserfs to ext4 but I have a couple disks with bad sectors on it. Ubuntu is reporting the disks are ok. disk1 currently has no bad sectors. I dont want to start migrating until I am sure I have a valid sync.
So basically three questions.
Thanks.
Last edit: molesza1 2015-02-06
You have a broken disk, making it read-only is standard kernel's way of dealing with it.
Stop any sync, get a new disk and recover either from the other disks+parity or try to copy as much as possible from the failing disk. Then, after you MAKE SURE you have EVERYTHING you need from the failed disk you can change snapraid to point to the new disk and sync again.
You can confirm the disk is broken with badblocks. But I advise not to stress the disk until you recovered first everything you wanted from there. In particular do not do any sync until you finished the recovery and double and triple checked you have all the data you want.
Thanks for the reply John
Thats terrible news. Is there anyway to confirm with ubuntu that it has put the disk into that state because of problems?
So is it possible that the file was not in fact deleted on the disk when it said it had been?
Normally you can test with badblocks but that will stress the drive a lot and I strongly recommend to avoid it for now if you still want the data from there.
Otherwise look in dmesg (either dmesg for current buffer or /var/log/dmesg for older events). I am sure it'll be full of all kinds of errors about this device and also there should be a message about making it read-only because of errors.
Once the device is bad you can't trust it, probably the delete operation (which is in fact just a write operation) failed, or the drive tried to relocate the sector to some other place and it failed, etc.
That all makes sense. Thanks VERY much for your help. I will diagnose when i get home tonight. Pity I dont have a hot spare! Will let you know how I get on. Thanks