u-boot.git/fs, branch v2019.07-rc2

fs: btrfs: add zstd decompression support

2019-05-05T12:48:50Z

This adds decompression support for Zstandard, which has been included in Linux btrfs driver for some time. Signed-off-by: Marek Behún

fs: btrfs: fix btrfs methods return values on failure

2019-05-03T11:30:31Z

The btrfs implementation methods .ls(), .size() and .read() returns 1 on failure, but the command handlers expect values <0 on failure. For example if given a nonexistent path, the load command currently returns success, and hush scripting does not work. Fix this by setting return values of these methods to -1 instead of 1 on failure. Signed-off-by: Marek Behún

fs: btrfs: Do not print mount fail message when not btrfs filesystem

2019-05-03T11:23:17Z

Other filesystem drivers don't do this. Signed-off-by: Marek Behún

Revert "fs: btrfs: fix false negatives in ROOT_ITEM search"

2019-04-27T15:35:44Z

Per Pierre this change shouldn't have been applied as it was superseded by "fs: btrfs: fix btrfs_search_tree invalid results" which is also applied now as 1627e5e5985d. This reverts commit 633967f9818cb6a0e87ffa8cba33148a5bcc6edb. Signed-off-by: Tom Rini

fs: btrfs: fix btrfs_search_tree invalid results

2019-04-26T21:53:16Z

btrfs_search_tree should return the first item in the tree that is greater or equal to the searched item. The search algorithm did not properly handle the edge case where the searched item is higher than the last item of the node but lower than the first item of the next node. Instead of properly returning the first item of the next node, it was returning an invalid path pointer (pointing to a non-existent item after the last item of the node + 1). This fixes two issues in the btrfs driver: - Looking for a ROOT_ITEM could fail if it was the first item of its leaf node. - Iterating through DIR_INDEX entries (for readdir) could fail if the first DIR_INDEX entry was the first item of a leaf node. Signed-off-by: Pierre Bourdon Cc: Marek Behun

fs: fat: Build only if CONFIG_FS_FAT=y

2019-04-26T21:53:16Z

Signed-off-by: Ismael Luceno

fs: btrfs: fix false negatives in ROOT_ITEM search

2019-04-26T21:53:15Z

ROOT_ITEMs in btrfs are referenced without knowing their actual "offset" value. To perform these searches using only two items from the key, the btrfs driver uses a special "btrfs_search_tree_key_type" function. The algorithm used by that function to transform a 3-tuple search into a 2-tuple search was subtly broken, leading to items not being found if they were the first in their tree node. This commit fixes btrfs_search_tree_key_type to properly behave in these situations. Signed-off-by: Pierre Bourdon Cc: Marek Behun

Fix ext4 block group descriptor sizing

2019-04-10T00:04:06Z

Ext4 allows for arbitrarily sized block group descriptors when 64-bit addressing is enabled, which was previously not properly supported. This patch dynamically allocates a chunk of memory of the correct size. Signed-off-by: Benjamin Lim

fs: fat: fix reading non-cluster-aligned root directory

2019-04-10T00:04:04Z

A FAT12/FAT16 root directory location is specified by a sector offset and it might not start at a cluster boundary. It also resides before the data area (before cluster 2). However, the current code assumes that the root directory is located at a beginning of a cluster, causing no files to be found if that is not the case. Since the FAT12/FAT16 root directory is located before the data area and is not aligned to clusters, using unsigned cluster numbers to refer to the root directory does not work well (the "cluster number" may be negative, and even allowing it be signed would not make it properly aligned). Modify the code to not use the normal cluster numbering when referring to the root directory of FAT12/FAT16 and instead use a cluster-sized offsets counted from the root directory start sector. This is a relatively common case as at least the filesystem formatter on Win7 seems to create such filesystems by default on 2GB USB sticks when "FAT" is selected (cluster size 64 sectors, rootdir size 32 sectors, rootdir starts at half a cluster before cluster 2). dosfstools mkfs.vfat does not seem to create affected filesystems. Signed-off-by: Anssi Hannula Reviewed-by: Bernhard Messerklinger Tested-by: Bernhard Messerklinger

fs: ext4: Problem with ext4load and sparse files

2019-04-10T00:04:03Z

Hi, when I try to load a sparse file via ext4load, I am getting the error message 'invalid extent' After a deeper look in the code, it seems to be an issue in the function ext4fs_get_extent_block in fs/ext4/ext4_common.c: The file starts with 1k of zeros. The blocksize is 1024. So the first extend block contains the following information: eh_entries: 1 eh_depth: 1 ei_block 1 When the upper layer (ext4fs_read_file) asks for fileblock 0, we are running in the 'invalid extent' error message. For me it seems, that the code is not prepared for handling a sparse block at the beginning of the file. The following change, solved my problem: I am really not an expert in ext4 filesystems. Can somebody please have a look at this issue and give me a feedback, if I am totally wrong or not?