u-boot.git/fs/btrfs, branch v2022.01

btrfs: Use U-Boot API for decompression

2021-10-08T19:53:26Z

Use the common function to avoid code duplication. Acked-by: Qu Wenruo Signed-off-by: Simon Glass

WS cleanup: remove SPACE(s) followed by TAB

2021-09-30T13:08:16Z

Signed-off-by: Wolfgang Denk

WS cleanup: remove excessive empty lines

2021-09-30T12:08:56Z

Signed-off-by: Wolfgang Denk

btrfs: Suppress the message about missing filesystem

2021-09-16T17:19:25Z

This message comes up a lot when scanning filesystems. It suggests to the user that there is some sort of error, but in fact there is no reason to expect that a particular partition has a btrfs filesystem. Other filesystems don't print this error. Turn it into a debug message. Signed-off-by: Simon Glass Reviewed-by: Marek Behún Reviewed-by: Qu Wenruo

btrfs: Use default subvolume as filesystem root

2021-09-01T14:11:24Z

BTRFS volume consists of a number of subvolumes which can be mounted separately from each other. The top-level subvolume always exists even if no subvolumes were created manually. A subvolume can be denoted as the default subvolume i.e. the subvolume which is mounted by default. The default "default subvolume" is the top-level one, but this is far from the common practices used in the wild. For instance, openSUSE provides an OS snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root filesystem is located into a separate subvolume which is "default" but not "top-level". That means that the /boot/dtb/ directory is also located inside this default subvolume instead of top-level one. However, the existing btrfs u-boot driver always uses the top-level subvolume as the filesystem root. This behaviour 1) is inconsistent with mount /dev/sda1 /target command, which mount the default subvolume 2) leads to the issues when /boot/dtb cannot be found properly (see the reference). This patch uses the default subvolume as the filesystem root to overcome mentioned issues. Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656 Signed-off-by: Matwey V. Kornilov Fixes: f06bfcf54d0e ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs") Reviewed-by: Qu Wenruo

Use LIB_UUID with ACPIGEN and FS_BTRFS

2021-07-28T18:27:54Z

Since the ACPI-generation code makes use of UUIDs we typically need to enabled UUID support for it to build. Add a new Kconfig condition. Use it for BTRFS also. Signed-off-by: Simon Glass

fs: btrfs: Add missing cache aligned allocation

2021-05-26T21:26:07Z

The superblock buffer must be cache aligned, since it might be used in DMA context, allocate it using ALLOC_CACHE_ALIGN_BUFFER() just like it was done in btrfs_read_superblock() and read_tree_node(). This fixes this output on boot and non-working btrfs on iMX53: CACHE: Misaligned operation at range [ced299d0, ced2a9d0] Signed-off-by: Marek Vasut Cc: Marek Behún Cc: Qu Wenruo Reviewed-by: Marek Behún

fs: btrfs: fix the false alert of decompression failure

2021-04-27T12:05:30Z

There are some cases where decompressed sectors can have padding zeros. In kernel code, we have lines to address such situation: /* * btrfs_getblock is doing a zero on the tail of the page too, * but this will cover anything missing from the decompressed * data. */ if (bytes < destlen) memset(kaddr+bytes, 0, destlen-bytes); kunmap_local(kaddr); But not in U-boot code, thus we have some reports of U-boot failed to read compressed files in btrfs. Fix it by doing the same thing of the kernel, for both inline and regular compressed extents. Reported-by: Matwey Kornilov Link: https://bugzilla.suse.com/show_bug.cgi?id=1183717 Fixes: a26a6bedafcf ("fs: btrfs: Introduce btrfs_read_extent_inline() and btrfs_read_extent_reg()") Signed-off-by: Qu Wenruo

fs: btrfs: do not fail when offset of a ROOT_ITEM is not -1

2021-03-01T14:53:46Z

When the btrfs_read_fs_root() function is searching a ROOT_ITEM with location key offset other than -1, it currently fails via BUG_ON. The offset can have other value than -1, though. This can happen for example if a subvolume is renamed: $ btrfs subvolume create X && sync Create subvolume './X' $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: X$ location key (270 ROOT_ITEM 18446744073709551615) type DIR transid 283 data_len 0 name_len 1 name: X $ mv X Y && sync $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: Y$ location key (270 ROOT_ITEM 0) type DIR transid 285 data_len 0 name_len 1 name: Y As can be seen the offset changed from -1ULL to 0. Do not fail in this case. Signed-off-by: Marek Behún Cc: David Sterba Cc: Qu Wenruo Cc: Tom Rini

fs: btrfs: change directory list output to be aligned as before

2021-02-24T21:51:48Z

Since commit 325dd1f642dd ("fs: btrfs: Use btrfs_iter_dir() to ...") when btrfs is listing a directory, the output is not aligned: 15 Wed Sep 09 13:20:03 2020 boot.scr -> @/boot/boot.scr 0 Tue Feb 02 12:42:09 2021 @ 108 Tue Feb 02 12:54:04 2021 1.info Return back to how it was displayed previously, i.e.: 15 Wed Sep 09 13:20:03 2020 boot.scr -> @/boot/boot.scr 0 Tue Feb 02 12:42:09 2021 @ < > 108 Tue Feb 02 12:54:04 2021 1.info Instead of '', print '< >', as ext4 driver. If an unknown directory item type is encountered, we will print the type number left padded with spaces, enclosed by '?', instead of '<' and '>', i.e.: ? 30? ............................. name Signed-off-by: Marek Behún Fixes: 325dd1f642dd ("fs: btrfs: Use btrfs_iter_dir() to replace ...") Cc: David Sterba Cc: Qu Wenruo Cc: Tom Rini Reviewed-by: Qu Wenruo