Continuing with putting Rockstor through its paces
I’d like to use a 2Tb disk that I’ve got, however because of a crash, I know that its got 8 sector errors at the end of the disk - previously, I’ve been able to create partitions manually that mean I avoid the bad sectors…
Reading the docs, it says that Rockstor uses the whole disk - is there a way to get around this so I can use my disk? E.g. is there a way to manually introduce a disk into the system, or a way to get btrfs to not use the bad sectors - I know a scrub should identify bad sectors, but I’d want to avoid a corruption to a file…
I’ve done this ‘partition around duff bits’ myself in the past but that was way before Rockstor and even btrfs itself. Always struck me as a neat trick and wringing the very last use of an otherwise peaky drive (in non critical roles of course) was handy.
Unfortunately, although Rockstor, stable at least, can do ‘btrfs in partition’ it’s really very beta level and just not recommended; the latest stable release of 3.9.2-48 also has a known bug which has been fixed in pending code to be released as 3.9.2-49. I.e. from the pending pr to sort this we have:
Fix prior TODO: re btrfs in partition failure point introduced in git tag 3.9.2-32.
You don’t say which version of Rockstor you are running but this capability should be back in play with 3.9.2-49 at beta level. But it really is best to avoid partitions as it’s just another level of complexity that we just don’t need anymore with the btrfs whole disk capability. But whatever, in stable channel updates version 3.9.2-31 was last known working for this capability.
But in your case, and if you are happy to potentially end up with a broken system, you could try it. See the Disks doc section which has info on how we deal with this. In short it’s essentially via a redirect role: you pick a partition on the disk to use and then use that disk as if it’s a whole disk. Only one btrfs partition per physical device is allowed. Rockstor simply re-directs all request to the ‘named’ / redirected partition. But also very much not recommended really but it did work for quite some time and I intent to give it some more attention once I’m less distracted with current server backend stuff. I’d say post 3.9.2-49 it should be workable again but if you’r game then give it a go. Can’t remember where last testing release was on this front as it’s now rather old but it may have been in there. See Intro section of the following forum thread for our current arrangements re the update channels: 3.9.2-# Stable Channel Changelog
I’ve also forced drives to re-map sectors by running a full DBAN on them. That way you don’t have to bother with the partition stuff. But I’d pair the drive thereafter with another in raid1 and do regular scrubs. Oh and non critical use again of course.
We have a section on running DBAN in our Pre-Install Best Practice (PBP) doc, subsection Wiping Disks (DBAN) obviously this is to be done on a machine where there are no other drives attached; just in case .
As DBAN essentially writes to all parts of the disk, when the disk notices it’s failing on a sector it will often manage to ‘hardwire’ within it’s own firmware a substitute sector from a collection it keeps aside for this purpose. Might work for you. You could look at the S.M.A.R.T. data within Rockstor both before and after. What you are looking for are the:
Current_Pending_Sector - don’t want any of these Reallocated_Sector_Ct - prior successful re-allocations
DBAN can ‘encourage’ the drive to move pending to reallocated, thus working around known bad sectors at the drive firmware level.
