Hi,
Has anyone tried a tiering filesystem like one of these?
https://bbs.archlinux.org/viewtopic.php?id=113529 http://www.lessfs.com/wordpress/?p=776
I've read that btrfs can do it also but is that stable enough for production yet?
If you have used any of the above, did it perform well?
As always, thanks ahead of time.
--- Will Y.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/10/14 10:42, aragonx@dcsnow.com wrote:
I've read that btrfs can do it also but is that stable enough for production yet?
If you have used any of the above, did it perform well?
I've never used any Tiering FS's, but I've got three production level Fedora VMs using btrfs as well as my desktop system (currently cross-compiling an arm kernel) using it. Seems to be able to take the load fine here. But then, we're a small shop and they aren't hammered 24/7.
My $0.02.
- -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.6-200.fc20.x86_64
On Apr 10, 2014, at 8:42 AM, aragonx@dcsnow.com wrote:
Hi,
Has anyone tried a tiering filesystem like one of these?
https://bbs.archlinux.org/viewtopic.php?id=113529 http://www.lessfs.com/wordpress/?p=776
I haven't seen much recent work with lvmts when I google it. I'm seeing a ton of work though with bcache, and dm-cache. These are the two competing methods for combining SSD and HDD. What I like about bcache is that the drive is pre-eminent, i.e. if the SSD dies, you're not left with a giant hole in the file system rendering all of your data corrupt. The HDD can still be normally mounted without the SSD, although it's possible it won't be in the same state as it was with the SDD alive. Also, the cache is assumed to always be dirty on start-up so the code that deals with "dirtiness" is well exercised. At least from my reading on paper, aside from bugs, it should reduce the likelihood of data loss in a power failure because commit times are reduced when cached to SSD instead of the HDD.
I've read that btrfs can do it also but is that stable enough for production yet?
Btrfs doesn't have any code so far for hybrid storage that incorporates an SSD as a cache.
The state of Btrfs is probably better qualified as usable in production if you have resources (current backups, spare drives, spare time) to deal with an unplanned problem while *testing* Btrfs. So if you're willing to be testing a file system in production, then it's usable in production. If you don't like the idea of testing a file system with production data, and don't have appropriate safeguards, and allowance for the downtime in case you have to completely rebuild (not merely repair), then don't use it.
Part of the "testing" factor is that if you encounter a problem, and neither a normal mount, nor -o recovery, nor -o ro,recovery works around it, you're pretty much expected to upgrade the kernel. Today that means 3.14.1 kernel, and v3.14 btrfs-progs; if not trying 3.15 from koji. And that's just because there's so much of the repair/recovery code in the kernel, and is used at mount time. The btrfsck is practically the last resort, and still the use of --repair isn't advised before exhausting other options first.
Chris Murphy
-
Chris Murphy -
Mark Haney -
Will Yonker