On Tue, 2008-09-09 at 19:32 -0600, Eric Anopolsky wrote: > > > Let's say I have 4 100GB drives (2 fast ones and 2 slow ones). I've > > > restricted a performance critical directory to the two fastest drives, > > > currently totaling 100GB of performance critical data. The rest of the > > > data on the system is striped. > > > > > > How much free space do I have on the filesystem? 100GB (the amount of > > > data I can store in the performance critical directory)? 200GB (the > > > amount of data I can store outside the performance critical directory if > > > the striping is guaranteed)? 300GB (the amount of data I can store > > > outside the performance critical directory if the striping is best > > > effort)? > > > > > > > People already create these configurations, they just do it with > > multiple filesystems. And, when they want to resize the performance > > critical section, it is a difficult (and often slow) operation. > > I think I'm starting to get it. btrfs would have drive groups, and no > file would have data on more than one drive group at once. That would > make it possible to make meaningful statements about how much free disk > space there is (per drive group). This is almost the same as having > multiple filesystems, except files cannot be assigned to filesystems on > an individual basis. Yes, I think this is a fair statement. > So in a way, btrfs would be replacing some > functionality of the VFS (mapping files to filesystems). I think there are many different definitions of the VFS. Mostly what the VFS does is maintain the dentry and inode caches, and provide a basic locking framework around most file/inode operations. The VFS is still doing all the mapping of files to filesystems, and the filesystem is mapping files to disk blocks. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
