Hello Recently I am learning about the Btrfs. My requirement is to construct a cross-device btrfs volume consisting of a single SSD and many (much larger) HDDs. The tricky part is that I want the SSD to be dedicated to metadata since SSDs are much faster (and more expensive) than HDDs and metadata are much more frequently queried than data. And I do not want ordinary data to use up the precious space on the SSD in case there would be no room for metadata. I have figured out that I can keep the metadata stored inside the first device by applying the "-m single" option to mkfs.btrfs. However, I do not know how to require that data should NOT be allocated on the SSD. I read the mkfs code. It appears to me that it can be worked around by excluding the SSD from the "raid group" for ordinary data. A recent patch have been proposed to move "hot" (according to statistics) data to SSDs in order to improve performance. My case is similar, but I know in advance that metadata are hotter. I am not very confident about what I have found, so I need some comment. Is it necessary to modify the Btrfs code? On the other hand, I have not figured out exactly how much metadata there would be with a given amount of data. How significant will it be to exclude ordinary data from the SSD? Kunshan Wang -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, I have a question to your requirement: If the meta is stored on the SSD and not on other HDDs, I think the SSD is must to be "online" whenever you mount any of the HDDs. And in other words, without the SSD, other HDDs are meaningless. Is that acceptable? regards, wengang. On 10-07-28 17:32, wks1986 wrote:> Hello > > Recently I am learning about the Btrfs. > > My requirement is to construct a cross-device btrfs volume consisting > of a single SSD and many (much larger) HDDs. The tricky part is that > I want the SSD to be dedicated to metadata since SSDs are much faster > (and more expensive) than HDDs and metadata are much more frequently > queried than data. And I do not want ordinary data to use up the > precious space on the SSD in case there would be no room for metadata. > > I have figured out that I can keep the metadata stored inside the > first device by applying the "-m single" option to mkfs.btrfs. > However, I do not know how to require that data should NOT be > allocated on the SSD. I read the mkfs code. It appears to me that it > can be worked around by excluding the SSD from the "raid group" for > ordinary data. > > A recent patch have been proposed to move "hot" (according to > statistics) data to SSDs in order to improve performance. My case is > similar, but I know in advance that metadata are hotter. > > I am not very confident about what I have found, so I need some > comment. Is it necessary to modify the Btrfs code? On the other > hand, I have not figured out exactly how much metadata there would be > with a given amount of data. How significant will it be to exclude > ordinary data from the SSD? > > Kunshan Wang > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, You are right. The single SSD would become a single point of failure. But if metadata should be mirrored in order to gain reliablilty, synchronizing between multiple devices may hurt performance. Mirroring between two SSDs should be reasonable, but synchronizing metadata between an SSD and an HDD may make it as slow as the slower HDD. So I think it is still necessary to control where metadata are stored. Another issue is the speed of fsck. There will always be times when the operating system is brought down abnormally and fsck is necessary. In order to make the downtime as short as possible, fsck should be fast. In this case, when metadata are stored in a fast device, fsck will be significantly faster. The "hot data tracking" patch is based on the statistics of ONLINE accesses. Some data may suddenly become hot when the filesystem goes offline for fsck. Kunshan Wang. 2010/7/28 Wengang Wang <wen.gang.wang@oracle.com>:> Hi, > > I have a question to your requirement: > > If the meta is stored on the SSD and not on other HDDs, I think the SSD is must > to be "online" whenever you mount any of the HDDs. And in other words, without > the SSD, other HDDs are meaningless. Is that acceptable? > > regards, > wengang. > On 10-07-28 17:32, wks1986 wrote: >> Hello >> >> Recently I am learning about the Btrfs. >> >> My requirement is to construct a cross-device btrfs volume consisting >> of a single SSD and many (much larger) HDDs. The tricky part is that >> I want the SSD to be dedicated to metadata since SSDs are much faster >> (and more expensive) than HDDs and metadata are much more frequently >> queried than data. And I do not want ordinary data to use up the >> precious space on the SSD in case there would be no room for metadata. >> >> I have figured out that I can keep the metadata stored inside the >> first device by applying the "-m single" option to mkfs.btrfs. >> However, I do not know how to require that data should NOT be >> allocated on the SSD. I read the mkfs code. It appears to me that it >> can be worked around by excluding the SSD from the "raid group" for >> ordinary data. >> >> A recent patch have been proposed to move "hot" (according to >> statistics) data to SSDs in order to improve performance. My case is >> similar, but I know in advance that metadata are hotter. >> >> I am not very confident about what I have found, so I need some >> comment. Is it necessary to modify the Btrfs code? On the other >> hand, I have not figured out exactly how much metadata there would be >> with a given amount of data. How significant will it be to exclude >> ordinary data from the SSD? >> >> Kunshan Wang >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
In response to your original questions, btrfs currently gives no control over the allocation of data or metadata. I''m sure someone will implement more control eventually. On Wed, Jul 28, 2010 at 11:49:33PM +0800, wks1986 wrote:> Another issue is the speed of fsck. There will always be times when > the operating system is brought down abnormally and fsck is necessary. > In order to make the downtime as short as possible, fsck should be > fast. In this case, when metadata are stored in a fast device, fsck > will be significantly faster. The "hot data tracking" patch is based > on the statistics of ONLINE accesses. Some data may suddenly become > hot when the filesystem goes offline for fsck.Actually, because of copy-on-write and other aspects of btrfs'' design, there''s no need for the typical use of fsck after a crash. Even once a proper fsck is finished, it will only be necessary when important information is corrupted. So it generally doesn''t make sense to worry about fsck speed. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html