Handle unaligned read at fs layer?

[Tom Rini]

On Sat, Apr 16, 2022 at 08:54:48AM +0800, Qu Wenruo wrote:
> Hi U-boot fs guys,
> 
> With my previous rework on U-boot btrfs, and my own btrfs-fuse project,
> it turns out that, although U-boot implements its fs with a very fuse
> like interface, there are still some quality-of-life features missing.
> 
> One of the most obvious one is making each fs to handle unaligned read.
> 
> This is especially obvious when comparing btrfs-fuse btrfs_file_read()
> against U-boot btrfs_file_read().
> 
> They share almost the same main loop, but btrfs_file_read() in U-boot
> have two extra handling, for unaligned leading sector and unaligned
> tailing sector.
> 
> 
> So I just did a quick check on the other fses, it turns out that we have
> a very different behaviors:
> 
> - FAT
> - Ext4
>   Have the handling for both tailing and ending block.
> 
> - Btrfs
>   My code, doing unaligned leading/tailing block manually.
>   (the tailing part looks unnecessary though)
> 
> - Ubifs
>   Explicitly reject read with non-aligned offset.
> 
> - Squshfs
>   Explicitly reject read with non-zero offset.
> 
> - Erofs
>   Have the handling for tailing unaligned part, but doesn't seem to
>   handle unaligned start part.
> 
> Thus if we have a proper common routine for unaligned read routine (get
> the file length, read the first and the last unaligned block, then let
> the .read callback to handle the aligned range), then all fs drivers
> would have a much better life.
> 
> Mind me to do such small but quality-of-life improve for all involved fses?
> (This will need a new call back to query the blocksize of each fs though)

If it seems like something that would generally improve fs support, and
I think that's what you're saying here, yes, please.  Thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220419/7c2177fd/attachment-0001.sig>