On Sun, Jul 17, 2016 at 10:26 AM, Matthias Prager <li...@matthiasprager.de> 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), but > drops of a cliff as soon as the internal buffer-region for > non-sequential writes fills up (even though I tested large file SMB > transfers). 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&id=7c4fbd50bfece00abf529bc96ac989dd2bb83ca4 so >= 4.4, as without this patch, it is quite problematic, if not impossible, to use this 8TB Seagate SMR drive with linux without doing other patches or setting/module changes. Since this patch, I have been using the drive for cold storage archiving, connected to a Baytrail SoC SATA port. I use bcache (writethrough or writearound) on an 8TB GPT partition that has a LUKS container that is Btrfs m-dup, d-single formatted and mounted compress=lzo,noatine,nossd. It is only powered on once a month for a day or so and then it receives incremental snapshots mostly or some SSD or flash images of 10-50G. I have more or less kept all the snapshots sofar, so chunks keep being added to previously unwritten space, so as sequential as possible. If free space would be heavily fragmented and also files would be heavily fragmented and the disk would be very full, adding new files or modifying would be very slow. You see than many seconds that the drive is active but no traffic on the SATA link. Also then there is the risk that the default '/sys/block/$(kerneldevname)/device/timeout' of 30 secs is too low, and that the kernel might reset the SATA link. A SATA link still happened 2x the last 1/2 year, I haven't really looked at the details sofar, just rebooted at some point in time later, but I will set the timeout at least higher, e.g. 180, and then see if ata errors/resets still occur. It might be FW crashes as well. > The only file system that worked really well with the 8TB Seagate SMR > drive was f2fs. I used 'mkfs.f2fs -o 0 -a 0 -s 9 /dev/sdx' to create one > and mounted it with noatime. -o means no additional over provisioning > (the 5% default is a lot of wasted space on a 8TB drive), -a 0 tells > f2fs not to use separate areas on the disks at the same time (which does > not perform well on hdds only on ssds) and finally -s 9 tells f2fs to > layout the file system in 1GB chunks. > I hammered this file system for some days (via SMB and via shred-script) > and it worked really well (performance and stability wise). Interesting that f2fs works well, although now thinking a bit, I am not so surprised that it works better than ext4 > I am considering using SMR drives for the next upgrades in my storage > server in the basement - the only things missing in f2fs are checksums > and raid1 support. But in my current setup (md-raid1+ext4) I don't get > checksums either so f2fs+smr is still on my road-map. Long term, I would > really like to switch to btrfs with it's built-in check summing (which > unfortunately does not work with NOCOW) and raid1. But some of the file > systems are almost 100% filled and I'm not trusting btrfs's stability > yet (and the manageability / handling of btrfs lacks behind compared to > say zfs). At least this SMR drive is not advised to use in raid setups. As not-so-active array it might work if you use the right timeouts and scterc etc, but if have seen how long the wait on the SATA link can be and that makes me realize that the stamp 'Archive Drive' done by Seagate has a clear reason. -- 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
