I'd like to attend LSF/MM this year. I'm involved in btrfs development for 5 years and one of the maintainers since early 2015. * Filesystems There are topics I'd like to discuss with other btrfs developers as this would be more interactive than the mail discussions. Hopefully this will cover things that never make it to the mails. As an example, the direction of the development, taming the patch flow and other maintainer pleasures. * FS/MM I'd like to participate in the discussions about refining the GFP flags and memory error handling in btrfs in general. It's not a secret that the current implementation is not robust. I've started with the low-hanging fruit for 4.5, getting rid of GFP_NOFS in the easy cases. The core work is still left untouched as this requires identifying all the paths/contexts that might recurse back to the filesystem. So far I was able to narrow down a few classes based on the expected object lifetime and possible IO involved. Namely for the short-lived allocations (eg. btrfs_path that's used for search & modify the metadata in the b-tree) it's crucial in many places not to fail. Here I'm thinking about some emergency reserves that would kick in if the slab/kmalloc allocation fails. That would be even after a GFP_HIGH fails so it's expected to be very rare and used at limited number of call sites. This could be potentially made a more generic part of the allocator. * MM, debugging helpers During the analysis I wanted to track per call-site allocation stats (count, size), and wrote basic version, stats exported via debugfs. Next to that is a desire for a better fault injection framework, eg. when I want to exercise a specific call path. Though I can implement it myself as needed, I assume that such extension of the existing code could be useful to others. (This could be considered marginal and not appropriate for the conference, but I feel I should mention it as a followup to the previous paragraph.) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
