mbox series

[RFC,00/31] btrfs buffered iomap support

Message ID cover.1623567940.git.rgoldwyn@suse.com (mailing list archive)
Headers show
Series btrfs buffered iomap support | expand

Message

Goldwyn Rodrigues June 13, 2021, 1:39 p.m. UTC 
From: Goldwyn Rodrigues <rgoldwyn@suse.com>

This is an attempt to perform the bufered read and write using iomap on btrfs.
I propose these changes as an RFC because I would like to know on your comments on the feasibility of going ahead with the design. It is not feature complete
with the most important support missing is multi-device and compression.
Sending to BTRFS mailing only for perspective from btrfs developers first.

Locking sequence change
One of the biggest architecture changes is locking extents before pages.
writepage(), called during memory pressure provides the page which is locked
already. Perform a best effort locking and work with what is feasible.
For truncate->invalidatepage(), lock the pages before calling setsize().
Are there any other areas which need to be covered?

TODO
====

Bio submission for multi-device
  Multi-device submission would require some work with respect to asynchronous
  completions. iomap can merge bio's making it larger than extent_map's
  map_length. There is a check in btrfs_map_bio which WARN()s on this.
  Perhaps a more modular approach of having callbacks would be easier to
  deal with.

Compression
  This would require extra flags to iomap, say type IOMAP_ENCODED, which would
  require iomap to read/write complete extents as opposed to performing I/O on
  only what is requested. An additional field io_size would be required to
  know how much of compressed size maps to uncompressed size.


Known issues
============
 BIO Submission: described above
 Random WARN_ON in kernel/locking/lockdep.c:895 points to memory corruption.

Finally, I have added some questions in the patch headers as well.