On Sun, May 19, 2013 at 6:41 PM, Martin Steigerwald <Martin@xxxxxxxxxxxx> wrote: > Am Donnerstag, 9. Mai 2013, 07:13:56 schrieb Zhi Yong Wu: >> HI, all > > Hi! > >> I saw that bcache will be merged into kernel upstream soon, so i >> want to know if btrfs hot relocation support is still meanful, if no, >> i will not continue to work on it. can anyone let me know this? >> thanks. > > I really look forward to VFS hot data tracking with BTRFS (and other > filesystem) support. I also really want to see this will happen. > > ZFS and BTRFS have shown that RAID support within the filesystem can make a lot > of sense. I think hot relocation is another area which can be done more > accurate within the filesystem. I think there are several features only > possible by going this route: > > 1) Mark files as hot via ioctl. MySQL can mark InnoDB journal files for example. It has been implemented to get its hot status of one specified file via ioctl. It is not hard to enable its set function. Before it is done, i more hope that the core of VFS hot tracking can get merged by kernel upstream. You know, it is harder if too new functions have been done. We can put it in to-do list at first, what do you think? > > 2) Proper BTRFS RAID support (as noted elsewhere in this thread) > > 3) Easier setup. With BTRFS flexibility I would expect that a SSD as hot data > cache can be added and removed on the fly during filesystem is mounted. Only > seems supported at mkfs-time as I read the patch docs, but from my basic > technical understanding of BTRFS it can be extented to be done on the fly with > a mounted FS as well. Yes, it is supported only at mkfs time. It shouldn't be hard to enable adding or removing a nonrotating disk as hot cache on the fly. You know, before this is done, i would like to make sure that the current design for BTRFS hot relocation is this RFC patchset is going in the direction and is appropriate. If it is going in wrong direction, we will be doing a lot of meanless work. E.g. How about the current idea on introducing one new block group for nonrotating disks. When working on this work, i were trying to change the least current btrfs code as far as possible. You know, if we change too many current btrfs code, it will introduce regression bug more easily, and so the patchset will be also harder to get accepted by btrfs upstream. What do you think? > > > Block based caching can make sense for other use cases like raw device with > Oracle DB on it or maybe a swap device. Or for filesystems not (yet) supporting > VFS hot data tracking. > > Thanks, > -- > Martin 'Helios' Steigerwald - http://www.Lichtvoll.de > GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- Regards, Zhi Yong Wu -- 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
