Message ID | cover.1611627788.git.naohiro.aota@wdc.com (mailing list archive) |
---|---|
Headers | show |
Series | btrfs: zoned block device support | expand |
On 26/01/2021 20:31, Naohiro Aota wrote: > This series adds zoned block device support to btrfs. Some of the patches > in the previous series are already merged as preparation patches. > > This series is also available on github. > Kernel https://github.com/naota/linux/tree/btrfs-zoned-v14 > Userland https://github.com/naota/btrfs-progs/tree/btrfs-zoned > xfstests https://github.com/naota/fstests/tree/btrfs-zoned > > Userland tool depends on patched util-linux (libblkid and wipefs) to handle > log-structured superblock. To ease the testing, pre-compiled static linked > userland tools are available here: > https://wdc.app.box.com/s/fnhqsb3otrvgkstq66o6bvdw6tk525kp > > v11 restructured the series so that it starts with the minimum patches to > run emulated zoned mode on regular devices (chunk/extent allocator, > allocation pointer handling, pinning of freed extents (re-dirtying released > extent)). > > This series still leaves the following issues left for later fix. > - Bio submission path & splitting an ordered extent > - Redirtying freed tree blocks > - Switch to keeping it dirty > - Not working correctly for now > - Dedicated tree-log block group > - We need tree-log for zoned device > - Dbench (32 clients) is 85% slower with "-o notreelog" > - Need to separate tree-log block group from other metadata space_info > - Relocation > - Use normal write command for relocation > - Relocated device extents must be reset > - It should be discarded on regular btrfs too though > - Support for zone capacity Hi David, I know we're late for 5.12, but the series has next to no potential for regressions on normal btrfs is there any chance we get get it staged? btrfs-progs and xfstests patches will follow soon as well.
On Fri, Jan 29, 2021 at 07:56:14AM +0000, Johannes Thumshirn wrote: > On 26/01/2021 20:31, Naohiro Aota wrote: > > This series adds zoned block device support to btrfs. Some of the patches > > in the previous series are already merged as preparation patches. > > > > This series is also available on github. > > Kernel https://github.com/naota/linux/tree/btrfs-zoned-v14 > > Userland https://github.com/naota/btrfs-progs/tree/btrfs-zoned > > xfstests https://github.com/naota/fstests/tree/btrfs-zoned > > > > Userland tool depends on patched util-linux (libblkid and wipefs) to handle > > log-structured superblock. To ease the testing, pre-compiled static linked > > userland tools are available here: > > https://wdc.app.box.com/s/fnhqsb3otrvgkstq66o6bvdw6tk525kp > > > > v11 restructured the series so that it starts with the minimum patches to > > run emulated zoned mode on regular devices (chunk/extent allocator, > > allocation pointer handling, pinning of freed extents (re-dirtying released > > extent)). > > > > This series still leaves the following issues left for later fix. > > - Bio submission path & splitting an ordered extent > > - Redirtying freed tree blocks > > - Switch to keeping it dirty > > - Not working correctly for now > > - Dedicated tree-log block group > > - We need tree-log for zoned device > > - Dbench (32 clients) is 85% slower with "-o notreelog" > > - Need to separate tree-log block group from other metadata space_info > > - Relocation > > - Use normal write command for relocation > > - Relocated device extents must be reset > > - It should be discarded on regular btrfs too though > > - Support for zone capacity > > > Hi David, > > I know we're late for 5.12, but the series has next to no potential for regressions > on normal btrfs is there any chance we get get it staged? Yes it's on the radar for 5.12 because of the low risk and relatively isolated changes, I don't want to let it slip to the next cycle. I'll add it to for-next for testing coverage, merge will happen probably early next week.
On 29/01/2021 21:46, David Sterba wrote: > Yes it's on the radar for 5.12 because of the low risk and relatively > isolated changes, I don't want to let it slip to the next cycle. I'll > add it to for-next for testing coverage, merge will happen probably > early next week. Thanks a lot, I've sent fixes for the build failures reported for for-next. My apologies that this slipped through. Byte, Johannes