Am Sonntag, 19. Mai 2013, 21:43:14 schrieb Zhi Yong Wu: > 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: […] > > 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? Yes, of course. I didn´t want to imply that you have to implement it. I didn´t contribute to BTRFS code yet, so I do not see myself in a position to request anything from you – and even if I did, what you code is still your decision. Many thanks for your work on this! I just wanted to note that IMHO its possible with the VFS approach while its at least difficult to do with the block layer based approaches. > > 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? Yes, see above. Keep it simple and extend later I´d say :) Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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
