On 2016-07-17 05:08, Hendrik Friedel wrote:
Hi Thomasz,
@Dave I have added you to the conversation, as I refer to your notes
(https://github.com/kdave/drafts/blob/master/btrfs/smr-mode.txt)
thanks for your reply!
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
TGMR is a derivative of giant magneto-resistance, and is what's been
used in hard disk drives for decades now. With limited exceptions in
recent years and in ancient embedded systems, all modern hard drives are
TGMR based.
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.
This type of performance degradation is actually not unexpected
depending on the physical location of the files on disk. Based on the
numbers you gave, the datasheet for the disk itself, and some basic
math, I'd guess that the two files ended up on opposite edges of a
single platter, which means that the head is seeking back and forth
almost constantly, which is what's killing your performance.
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
Well, btrfs does write data very different to many other file systems.
On every write the file is copied to another place, even if just one bit
is changed. That's special and I am wondering whether that could cause
problems.
There's two things that should be clarified here:
1. BTRFS only copies part of the file, not the whole file. At most, it
copies out a single block, which on reasonably sized filesystems is 16k
these days.
2. Copy-on-write semantics are not as special as you might think, ZFS is
also a COW filesystem, as are all log-structured filesystems (NILFS2,
LogFS, LFS, WAFL, and a couple of others), and a number of filesystems
support it to some degree (OCFS2, XFS, and even NTFS).
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 ...
Well, I'm no pro. But I found this:
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.
And I am wondering:
a) whether it is advisable to use BTRFS on these drives before these
improvements have been made already
i) if not: Are there specific btrfs features that should be avoided,
or btrfs in general?
It's fine to use BTRFS, you just have to give the drive time to finish
it's internal bookkeeping before you power it off. The same is true
with any filesystem, it's just that COW filesystems that aren't log
structured tend to require a lot more internal bookkeeping on the drive
than traditional filesystems. On a typical non-COW filesystem, this
takes maybe a minute or two depending on the amount of data written. On
a log structured filesystem, it may take only 15-30 seconds (log
structured filesystems are more similar to the internal layout of an SMR
drive than most other filesystems). For a COW filesystem like BTRFS, it
may take 10-30 minutes depending on how much data got moved because of
the COW semantics. It's worth pointing out that these numbers are for
archival usage (write a few big files infrequently), they go up pretty
steeply for more traditional usage such as for a root filesystem.
b) whether these improvements have been made already
Not yet.
care about your data, do some research ... if not ... maybe raiserFS
is for you :)
You are right for sure. And that's what I do here. But I am far away
from being able to judge myself, so I rely on support.
The fact that you're doing research at all is still better than many
users I see.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
