Bill Davidsen wrote:
> I believe that implementing RAID in the filesystem has many benefits
too:
> - multiple RAID levels: store metadata in triple-mirror RAID 1, random
> write intensive data in RAID 1, bulk data in RAID 5/6
> - improved write throughput - since stripes can be variable size, any
> large enough write fills a whole stripe
>
I rather like the idea of allowing metadata to be on another device in
general, or at least the inodes. That way a very small chunk size can be
used for the inodes, to spread head motion, while a larger chunk size is
appropriate for data in some cases.
If your workload is metadata intensive, your data disks are idle; if
you're reading data, the inode device is gathering dust. You can run out
of inodes before you run out of space and vice-versa. Very suboptimal.
A symmetric configuration allows full use of all resources for any
workload, at the cost of increased complexity - every extent has its own
RAID level and RAID component devices.
Larger max block sizes would be useful as well. Feel free to discuss the
actual value of "larger."
Filesystems should use extents, not blocks, avoiding the block size
tradeoff entirely.
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
