Re: Status of SMR with BTRFS

On 21 July 2016 at 15:34, Chris Murphy wrote: > > Do programs have a way to communicate what portion of a data file is > modified, so that only changed blocks are COW'd? When I change a > single pixel in a 400MiB image and do a save (to overwrite the > original file), it

Re: Status of SMR with BTRFS

On Thu, Jul 21, 2016 at 8:12 AM, Austin S. Hemmelgarn wrote: > This really isn't fake COW, it's COW, just at a higher level than most > programmers would think of it. Alright I'll stop calling it that. Thanks. -- Chris Murphy -- To unsubscribe from this list: send the

Re: Status of SMR with BTRFS

On 2016-07-21 09:34, Chris Murphy wrote: On Thu, Jul 21, 2016 at 6:46 AM, Austin S. Hemmelgarn wrote: On 2016-07-20 15:58, Chris Murphy wrote: On Sun, Jul 17, 2016 at 3:08 AM, Hendrik Friedel wrote: Well, btrfs does write data very different to

Re: Status of SMR with BTRFS

On Thu, Jul 21, 2016 at 4:34 PM, Chris Murphy wrote: > > Do programs have a way to communicate what portion of a data file is > modified, so that only changed blocks are COW'd? When I change a > single pixel in a 400MiB image and do a save (to overwrite the > original

Re: Status of SMR with BTRFS

On Thu, Jul 21, 2016 at 6:46 AM, Austin S. Hemmelgarn wrote: > On 2016-07-20 15:58, Chris Murphy wrote: >> >> On Sun, Jul 17, 2016 at 3:08 AM, Hendrik Friedel >> wrote: >> >>> Well, btrfs does write data very different to many other file systems. On

Re: Status of SMR with BTRFS

On 2016-07-20 15:58, Chris Murphy wrote: On Sun, Jul 17, 2016 at 3:08 AM, Hendrik Friedel wrote: 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

Re: Status of SMR with BTRFS

> I'd expect the write pattern of Btrfs to be similar to f2fs, with > respect to sequentiality of new writes. Ideally yes - though my tests with a Seagate SMR drive suggest otherwise. Optimizing the write behavior would probably lead to speed improvements for btrfs on spinning disks. --- Matthias

Re: Status of SMR with BTRFS

On Sun, Jul 17, 2016 at 3:08 AM, Hendrik Friedel wrote: > 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

Re: Status of SMR with BTRFS

Sorry for late reply, there was a lot of traffic in this thread so: 1. I do apologize but I've got a wrong end of the stick, I was convinced that btrfs does cause corruption on your disk because some of the link that you've hav in original post were pointing to topics with corruptions going on,

Re: Status of SMR with BTRFS

On 2016-07-18 15:05, Hendrik Friedel wrote: Hello Austin, thanks for your reply. Ok, thanks; So, TGMR does not say whether or not the Device is SMR or not, right? I'm not 100% certain about that. Technically, the only non-firmware difference is in the read head and the tracking. If it were

Re: Status of SMR with BTRFS

Hello Austin, thanks for your reply. Ok, thanks; So, TGMR does not say whether or not the Device is SMR or not, right? I'm not 100% certain about that. Technically, the only non-firmware difference is in the read head and the tracking. If it were me, I'd be listing SMR instead of TGMR on

Re: Status of SMR with BTRFS

18.7.2016, 0.44, Matthias Prager kirjoitti: the Seagate SMR drives are fast enough to handle Gbit-LAN speeds if they are served mostly large sequential chunks by the file system, which f2fs actually manages to do (cold storage in my scenario too). Btrfs does too many scattered writes for this

Re: Status of SMR with BTRFS

On 2016-07-18 14:31, Hendrik Friedel wrote: Hello and thanks for your replies, It's a Seagate Expansion Desktop 5TB (USB3). It is probably a ST5000DM000. this is TGMR not SMR disk: TGMR is a derivative of giant magneto-resistance, and is what's been used in hard disk drives for decades now.

Re: Status of SMR with BTRFS

Hello and thanks for your replies, It's a Seagate Expansion Desktop 5TB (USB3). It is probably a ST5000DM000. this is TGMR not SMR disk: 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

Re: Status of SMR with BTRFS

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.

Re: Status of SMR with BTRFS

Am 17.07.2016 um 22:10 schrieb Henk Slager: > What kernel (version) did you use ? > I hope it included: > http://git.kernel.org/cgit/linux/kernel/git/mkp/linux.git/commit/?h=bugzilla-93581=7c4fbd50bfece00abf529bc96ac989dd2bb83ca4 > > so >= 4.4, as without this patch, it is quite problematic, if

Re: Status of SMR with BTRFS

>>> 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

Re: Status of SMR with BTRFS

On Sun, Jul 17, 2016 at 10:26 AM, Matthias Prager wrote: > from my experience btrfs does work as badly with SMR drives (I only had > the opportunity to test on a 8TB Seagate device-managed drive) as ext4. > The initial performance is fine (for a few gigabytes / minutes),

Re: Status of SMR with BTRFS

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:

Re: Status of SMR with BTRFS

Hello Hendrik, from my experience btrfs does work as badly with SMR drives (I only had the opportunity to test on a 8TB Seagate device-managed drive) as ext4. The initial performance is fine (for a few gigabytes / minutes), but drops of a cliff as soon as the internal buffer-region for

Re: Status of SMR with BTRFS

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

Re: Status of SMR with BTRFS

Hello Tomasz, thanks for your reply. What disk are you using ? It's a Seagate Expansion Desktop 5TB (USB3). It is probably a ST5000DM000. 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 …

Re: Status of SMR with BTRFS

Thou I’m not a hardcore storage system professional: What disk are you using ? 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 … 2. SMR managed by host system, BTRFS still does see this as a

Status of SMR with BTRFS

Hello, I have a 5TB Seagate drive that uses SMR. I was wondering, if BTRFS is usable with this Harddrive technology. So, first I searched the BTRFS wiki -nothing. Then google. * I found this: https://bbs.archlinux.org/viewtopic.php?id=203696 But this turned out to be an issue not related to