| |||||||||||||
That's the setup I have - and HATE itThat's the setup I have - and HATE itPosted Jan 8, 2009 20:26 UTC (Thu) by roblucid (subscriber, #48964)In reply to: That's the setup I have - and HATE it by khim Parent article: Btrfs aims for the mainline
> Huh? Why "monolithic block of code"??? I'm perfectly happy with
> separating of functions - different filesystems are free to use the same > implementation of RAID, LVM, etc - if their authors decide it's the best > way to do things. Just as long as it's not exposed to userspace (or at > least to user).
Well you seemed to imply it by saying you couldn't imagine it being down outside of the filesystem.
Permitting layers, I could imagine some specialised "meta" filesystem being feasible, that would give you a name space, that lets you tag directories and files with storage characteristics using more traditional type file systems as backing stores for bulk data storage. The real files might end up in a file hierarchy, spread over a number of volumes a bit like http proxy caches, to provide manageable chunks of RAID1, RAID0, RAID5, RAID10 storage, which can be increased (and freed) on demand by the Disk Management System.
The only thing is, how many ppl would actually need that? And if it were provided, how many would ever use funky "Save As" options, in applications, compared to the number who would whinge about excessive options, being confusing and unclean in their precious GUI?
(Log in to post comments)
That's the setup I have - and HATE it Posted Jan 9, 2009 18:43 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Permitting layers, I could imagine some specialised "meta" filesystem being feasible, that would give you a name space, that lets you tag directories and files with storage characteristics using more traditional type file systems as backing stores for bulk data storage. I believe you're describing object storage. The lower of those layers is the object layer. But it differs from a traditional filesystem in that the only names the objects (files) have are made up by the system (essentially, inode numbers). In most of the work on object storage, that layer actually lives in a hardware unit separate from the one with the POSIX filesystem image, but it could be in the kernel between the filesystem drivers and the block device drivers as well (if it hasn't been done already). But we do need to ask whether there is a need to have more than one future filesystem type with this kind of storage function before we put a lot of effort into making a reusable layer.
|
|||||||||||||