>>> It's a Seagate Expansion Desktop 5TB (USB3). It is probably a >>> ST5000DM000. >> >> >> this is TGMR not SMR disk: >> >> http://www.seagate.com/www-content/product-content/desktop-hdd-fam/en-us/docs/100743772a.pdf >> So it still confirms to standard record strategy ... > > > I am not convinced. I had not heared TGMR before. But I find TGMR as a > technology for the head. > https://pics.computerbase.de/4/0/3/4/4/29-1080.455720475.jpg > > In any case: the drive behaves like a SMR drive: I ran a benchmark on it > with up to 200MB/s. > When copying a file onto the drive in parallel the rate in the benchmark > dropped to 7MB/s, while that particular file was copied at 40MB/s.
It is very well possible that for a normal drive of 4TB or so you get this kind of behaviour. Suppose you have 2 tasks, 1 writing in with 4k blocksize to a 1G file at the beginning of the disk and the 2nd with 4k blocksize to a 1G file at the end of the disk. At the beginning you get sustained ~150MB/s, at the end ~75MB/s. Between every 4k write (or read) you move the head(s), so ~4ms lost. I was wondering how big the zones etc are and hopefully this is still true: http://blog.schmorp.de/data/smr/fast15-paper-aghayev.pdf > https://github.com/kdave/drafts/blob/master/btrfs/smr-mode.txt > And this does sound like improvements to BTRFS can be done for SMR in a > generic, not vendor/device specific manner. Maybe have a look at recent patches from Hannes R from SUSE (to 4.7 kernel AFAIK) and see what will be possible with Btrfs once this 'zone-handling' is all working on the lower layers. Currently, there is nothing special in Btrfs for SMR drives in recent kernels, but in my experience it works, if you keep device-managed SMR characteristics/limitations in mind. Maybe like a tape-archive or dvd-burner. -- 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
