I would like to use this thread to ask few questions: If we have 2 devices dying on us and we run RAID6 - this theoretically will still run (despite our current problems). Now let’s say that we booted up raid6 of 10 disk and 2 of them dies but operator does NOT know what are dev ID of disk that died, How does one removes those devices other than using “-missing” ??? I ask because it’s in multiple places stated to use “replace” when your device dies but nobody ever states how to find out which /dev/ node is actually missing …. so when I want to use a replace, I don’t know what to use within command :/ … This whole thing might have an additional complication - if FS is fool, than one would need to add disks than remove missing.
> On 10 Jan 2017, at 21:49, Chris Murphy <li...@colorremedies.com> wrote: > > On Tue, Jan 10, 2017 at 2:07 PM, Vinko Magecic > <vinko.mage...@construction.com> wrote: >> Hello, >> >> I set up a raid 1 with two btrfs devices and came across some situations in >> my testing that I can't get a straight answer on. >> >> 1) When replacing a volume, do I still need to `umount /path` and then >> `mount -o degraded ...` the good volume before doing the `btrfs replace >> start ...` ? > > No. If the device being replaced is unreliable, use -r to limit the > reads from the device being replaced. > > > >> I didn't see anything that said I had to and when I tested it without >> mounting the volume it was able to replace the device without any issue. Is >> that considered bad and could risk damage or has `replace` made it possible >> to replace devices without umounting the filesystem? > > It's always been possible even before 'replace'. > btrfs dev add <dev3> > btrfs dev rem <dev1> > > But there are some bugs in dev replace that Qu is working on; I think > they mainly negatively impact raid56 though. > > The one limitation of 'replace' is that the new block device must be > equal to or larger than the block device being replaced; where dev add >> dev rem doesn't require this. > > >> 2) Everything I see about replacing a drive says to use `/old/device >> /new/device` but what if the old device can't be read or no longer exists? > > The command works whether the device is present or not; but if it's > present and working then any errors on one device can be corrected by > the other, whereas if the device is missing, then any errors on the > remaining device can't be corrected. Off hand I'm not sure if the > replace continues and an error just logged...I think that's what > should happen. > > >> Would that be a `btrfs device add /new/device; btrfs balance start >> /new/device` ? > > dev add then dev rem; the balance isn't necessary. > >> >> 3) When I have the RAID1 with two devices and I want to grow it out, which >> is the better practice? Create a larger volume, replace the old device with >> the new device and then do it a second time for the other device, or >> attaching the new volumes to the label/uuid one at a time and with each one >> use `btrfs filesystem resize devid:max /mountpoint`. > > If you're replacing a 2x raid1 with two bigger replacements, you'd use > 'btrfs replace' twice. Maybe it'd work concurrently, I've never tried > it, but useful for someone to test and see if it explodes because if > it's allowed, it should work or fail gracefully. > > There's no need to do filesystem resizes when doing either 'replace' > or 'dev add' followed by 'dev rem' because the fs resize is implied. > First it's resized/grown with add; and then it's resized/shrink with > remove. For replace there's a consolidation of steps, it's been a > while since I've looked at the code so I can't tell you what steps it > skips, what the state of the devices are in during the replace, which > one active writes go to. > > > -- > Chris Murphy > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
