Just please don't take it as picking or something: > 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 ... >> There are two types: >> 1. SMR managed by device firmware. BTRFS sees that as a normal block >> device … problems you get are not related to BTRFS it self … > > That for sure. But the way BTRFS uses/writes data could cause problems in > conjunction with these devices still, no? I'm sorry but I'm confused now, what "magical way of using/writing data" you actually mean ? AFAIK btrfs sees the disk as a block device ... for example devices has a very varying sector size, which is a 512 bytes + some CRC + maybe ECC ... btrfs does not access this data, drive does ... to be honest drives tend to lie to you continuously ! They use this ECC to magically bail out of bad sector, give you data and silently switch to spare sector ... Now think slowly and thoroughly about it: who would write a code (and maintain it) for a file system that access device specific data for X amount of vendors with each having Y amount of model specific configurations/caveats/firmwares/protocols ... S.M.A.R.T. emerged to give a unifying interface to device statistics ... this is how bad it was ... FYI, in 2009 I was creating a product with linux that was starting from a flash based FS ... some people required that data after 20 years would boot up unchanged ... my answer was: "HOW", yes I could ensure a certain files integrity in readout by checking md5, but I could not warrant a whole FS integrity ... specially at the time when j2ffs was only option on flash memories (yeah it had to be RW as well @#$*@#$) ... so btrfs comes along and takes away most of problems ... if you care about your data, do some research ... if not ... maybe raiserFS is for you :) -- 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
