I recommend to read this paper: https://www.toshiba.co.jp/tech/review/en/01_02/pdf/a08.pdf https://www.servethehome.com/surreptitiously-swapping-smr-into-hard-drives-must-end/ I think it very bad that WD did not declare that the disk is a SMR. The SMR code that is written expect the drive to inform the host about it status. The host manage SMR and Host aware SMR. The type WD red uses is Disk managed SMR, and our machines are unaware of it SMR usage. As far as I understand the problem that have been described by others, it is not the SMR its self that is the problem. The problem is that a user expect to be able to do random writes, like normal like the old WD red drives. But as the action of rebuild a raid is a sequential operation, when pared other writes is becomes random writes. So my understanding is that maybe SMR can be okay for setup with cache or setups with huge downtime, for the system to be able to rebuild without user writes. I am still looking for documentation to verify what is the break point, on how much other writes are acceptable during a rebuild before the linux kernel/FS will mark it as a bad drive. according to this test: https://www.youtube.com/watch?v=JDYEG4X_LCg WD red with SMR have better sequential read/write, during raid build, for a empty raid. according to this test: https://www.youtube.com/watch?v=0PhvXPVH-qE WD red with SMR have slightly slower sequential read/write, during raid build, for a empty raid. So what can BTRFS do. I think this is something that primeratly needs to handle at kernel level not filesystem level. Where one solution can be to temperatury slow the write speed to that manuel disk to have writes below disk rated level. A other solution can be to stop rebuild if writes fall below a level, for a some duration to allow the disk to move some of the data in media cache area over SMR area. But primarily there need to be a way to mark a DM-SMR disk with a "This is a SMR disk " similar to host managed and host aware SMR, so the kernel and/or filesystem can do something with it. -- Torstein Eide Torsteine@xxxxxxxxx
