Re: Tiering FS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Apr 10, 2014, at 8:42 AM, aragonx@xxxxxxxxxx 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

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux