aboutsummaryrefslogtreecommitdiff
path: root/fs/btrfs/disk-io.c
AgeCommit message (Collapse)Author
2023-01-11fs/btrfs: handle data extents, which crosss stripe boundaries, correctlyQu Wenruo
[BUG] Since btrfs supports single device RAID0 at mkfs time after btrfs-progs v5.14, if we create a single device raid0 btrfs, and created a file crossing stripe boundary: # mkfs.btrfs -m dup -d raid0 test.img # mount test.img mnt # xfs_io -f -c "pwrite 0 128K" mnt/file # umount mnt Since btrfs is using 64K as stripe length, above 128K data write is definitely going to cross at least one stripe boundary. Then u-boot would fail to read above 128K file: => host bind 0 /home/adam/test.img => ls host 0 < > 131072 Fri Dec 30 00:18:25 2022 file => load host 0 0 file BTRFS: An error occurred while reading file file Failed to load 'file' [CAUSE] Unlike tree blocks read, data extent reads doesn't consider cases in which one data extent can cross stripe boundary. In read_data_extent(), we just call btrfs_map_block() once and read the first mapped range. And if the first mapped range is smaller than the desired range, it would return error. But since even single device btrfs can utilize RAID0 profiles, the first mapped range can only be at most 64K for RAID0 profiles, and cause false error. [FIX] Just like read_whole_eb(), we should call btrfs_map_block() in a loop until we read all data. Since we're here, also add extra error messages for the following cases: - btrfs_map_block() failure We already have the error message for it. - Missing device This should not happen, as we only support single device for now. - __btrfs_devread() failure With this bug fixed, btrfs driver of u-boot can properly read the above 128K file, and have the correct content: => host bind 0 /home/adam/test.img => ls host 0 < > 131072 Fri Dec 30 00:18:25 2022 file => load host 0 0 file 131072 bytes read in 0 ms => md5sum 0 0x20000 md5 for 00000000 ... 0001ffff ==> d48858312a922db7eb86377f638dbc9f ^^^ Above md5sum also matches. Reported-by: Sam Winchenbach <swichenbach@tethers.com> Signed-off-by: Qu Wenruo <wqu@suse.com>
2022-10-17fs: Quieten down the filesystems moreSimon Glass
When looking for a filesystem on a partition we should do so quietly. At present if the filesystem is very small (e.g. 512 bytes) we get a host of messages. Update these to only show when debugging. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-09-29fs: btrfs: remove the usage of undeclared fs_mutex variablePankaj Raghav
This line probably got in by mistake as there is no fs_mutex member in the btrfs_fs_info struct. Signed-off-by: Pankaj Raghav <p.raghav@samsung.com> Reviewed-by: Qu Wenruo <wqu@suse.com>
2022-01-18fs/btrfs: add dependency on BLAKE2 hashQu Wenruo
Now btrfs can utilize the newly intorudced BLAKE2 hash. Signed-off-by: Qu Wenruo <wqu@suse.com>
2021-09-16btrfs: Suppress the message about missing filesystemSimon Glass
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 <sjg@chromium.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Qu Wenruo <wqu@suse.com>
2021-09-01btrfs: Use default subvolume as filesystem rootMatwey V. Kornilov
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 <matwey.kornilov@gmail.com> Fixes: f06bfcf54d0e ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs") Reviewed-by: Qu Wenruo <wqu@suse.com>
2021-05-26fs: btrfs: Add missing cache aligned allocationMarek Vasut
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 <marex@denx.de> Cc: Marek Behún <marek.behun@nic.cz> Cc: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2021-03-01fs: btrfs: do not fail when offset of a ROOT_ITEM is not -1Marek Behún
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 <marek.behun@nic.cz> Cc: David Sterba <dsterba@suse.com> Cc: Qu Wenruo <wqu@suse.com> Cc: Tom Rini <trini@konsulko.com>
2021-01-20fs: btrfs: simplify close_ctree_fs_info()Heinrich Schuchardt
At the beginning of close_ctree_fs_info() the value 0 is assigned to err and never changed before testing it. Let's get rid of the superfluous variable. Fixes: f06bfcf54d0e ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Qu Wenruo <wqu@suse.com>
2020-09-07fs: btrfs: Cleanup the old implementationQu Wenruo
This cleans up the now unneeded code from the old btrfs implementation. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2020-09-07fs: btrfs: Introduce btrfs_read_extent_inline() and btrfs_read_extent_reg()Qu Wenruo
These two functions are used to do sector aligned read, which will be later used to implement btrfs_file_read(). Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2020-09-07fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progsQu Wenruo
open_ctree_fs_info() is the main entry point to open btrfs. This version is a simplfied version of __open_ctree_fd() of btrfs-progs, the main differences are: - Parameters on how to specify a block device Instead of @fd and @path, U-Boot uses blk_desc and disk_partition_t. - Remove open_ctree flags There won't be multiple open ctree modes in U-Boot. Otherwise functions structures are all kept the same. With open_ctree_fs_info() implemented, also introduce the global current_fs_info pointer to show the current opened btrfs. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2020-09-07fs: btrfs: Crossport read_tree_block() from btrfs-progsQu Wenruo
This is the one of the basic stone function for btrfs, which: - Resolves the chunk mappings - Reads data from disk - Does various sanity check With read_tree_block(), we can finally crossport needed btrfs btree operations to U-Boot. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz>
2020-09-07fs: btrfs: Crossport btrfs_read_dev_super() from btrfs-progsQu Wenruo
This patch uses generic code from btrfs-progs to read one super block from block device. To support the btrfs-progs coding style, the following is also crossported: - BTRFS_SETGET_FUNC for btrfs_super_block - btrfs_check_super() function - Move btrfs_read_superblock() to disk-io.[ch] Since super.c only contains pretty small amount of code, and the extra check will be covered in later root read patches. Differences between this implementation and btrfs-progs: - No sbflags/sb_bytenr support Since we only need to read the primary super block (like kernel), sbflags/sb_bytenr used by super block recovery is not needed. This also changes the following behavior of U-Boot btrfs: - Only reads the primary super block The old implementation reads all 3 super blocks, and also one non-existing backup. This is not correct, especially if there is another filesystem created on the device but old superblocks are not rewritten. Just like kernel, we only check the primary super block. Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz> [trini: Change error to be a define in compat.h] Signed-off-by: Tom Rini <trini@konsulko.com>
2020-09-07fs: btrfs: Add more checksum algorithmsQu Wenruo
This mostly crossports crypto/hash.[ch] from btrfs-progs. The differences are: - No blake2 support No blake2 related library in U-Boot yet. - Use uboot xxhash/sha256 directly No need to implement the code as U-Boot has already provided the interface. This adds the support for the following csums: - SHA256 - XXHASH Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Marek Behún <marek.behun@nic.cz>