u-boot.git/fs/ext4, branch v2014.07

fs: ext4: fix writing zero-length files

2014-06-19T15:18:53+00:00

ext4fs_allocate_blocks() always allocates at least one block for a file.
If the file size is zero, this causes total_remaining_blocks to
underflow, which then causes an apparent hang while 2^32 blocks are
allocated.

To solve this, check that total_remaining_blocks is non-zero as part of
the loop condition (i.e. before each loop) rather than at the end of
the loop.

Signed-off-by: Stephen Warren

ext4: correctly zero filename

2014-06-11T20:27:05+00:00

Since ALLOC_CACHE_ALIGN_BUFFER declares a char* for filename
sizeof(filename) is not the size of the buffer. Use the already
known length instead.

cc: Uma Shankar 
cc: Manjunatha C Achar 
cc: Marek Vasut 
Signed-off-by: Jeroen Hofstee 
Acked-by: Marek Vasut

fs:ext4:write:fix: Reinitialize global variables after updating a file

2014-05-12T20:31:50+00:00

This bug shows up when file stored on the ext4 file system is updated.

The ext4fs_delete_file() is responsible for deleting file's (e.g. uImage)
data.
However some global data (especially ext4fs_indir2_block), which is used
during file deletion are left unchanged.

The ext4fs_indir2_block pointer stores reference to old ext4 double
indirect allocated blocks. When it is unchanged, after file deletion,
ext4fs_write_file() uses the same pointer (since it is already initialized
- i.e. not NULL) to return number of blocks to write. This trunks larger
file when previous one was smaller.

Lets consider following scenario:

1. Flash target with ext4 formatted boot.img (which has uImage [*] on itself)
2. Developer wants to upload their custom uImage [**]
	- When new uImage [**] is smaller than the [*] - everything works
	correctly - we are able to store the whole smaller file with corrupted
	ext4fs_indir2_block pointer
	- When new uImage [**] is larger than the [*] - theCRC is corrupted,
	since truncation on data stored at eMMC was done.
3. When uImage CRC error appears, then reboot and LTHOR/DFU reflashing causes
	proper setting of ext4fs_indir2_block() and after that uImage[**]
	is successfully stored (correct uImage [*] metadata is stored at an
	eMMC on the first flashing).

Due to above the bug was very difficult to reproduce.
This patch sets default values for all ext4fs_indir* pointers/variables.

Signed-off-by: Lukasz Majewski

fs:ext4:cleanup: Remove superfluous code

2014-05-12T20:31:50+00:00

Code responsible for handling situation when ext4 has block size of 1024B
can be ordered to take less space.

This patch does that for ext4 common and write files.

Signed-off-by: Lukasz Majewski

Revert "ext4fs: Add ext4 extent cache for read operations"

2014-02-26T13:18:58+00:00

This reverts commit fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5.

The author has asked on the mailing list that we revert this for now as
it breaks write support.

Reported-by: Łukasz Majewski 
Signed-off-by: Tom Rini

ext4fs: Add ext4 extent cache for read operations

2014-02-21T16:33:18+00:00

In an ext4 filesystem, the inode corresponding to a file has a 60-byte
area which contains an extent header structure and up to 4 extent
structures (5 x 12 bytes).

For files that need more than 4 extents to be represented (either files
larger than 4 x 128MB = 512MB or smaller files but very fragmented),
ext4 creates extent index structures. Each extent index points to a 4KB
physical block where one extent header and additional 340 extents could
be stored.

The current u-boot ext4 code is very inefficient when it tries to load a
file which has extent indexes. For each logical file block the code will
read over and over again the same blocks of 4096 bytes from the disk.

Since the extent tree in a file is always the same, we can cache the
extent structures in memory before actually starting to read the file.

This patch creates a simple linked list of structures holding information
about all the extents used to represent a file. The list is sorted by
the logical block number (ee_block) so that we can easily find the
proper extent information for any file block.

Without this patch, a 69MB file which had just one extent index pointing
to a block with another 6 extents was read in approximately 3 minutes.
With this patch applied the same file can be read in almost 20 seconds.

Signed-off-by: Ionut Nicu

ext4: implement exists() for ext4fs

2014-02-19T14:47:34+00:00

This hooks into the generic "file exists" support added in an earlier
patch, and provides an implementation for the ext4 filesystem.

Signed-off-by: Stephen Warren 
Acked-by: Simon Glass

ext4fs: fix "invalid extent block" error

2014-01-20T15:09:40+00:00

For files where we actually have extent indexes following
an extent header (ext_block->eh_depth != 0), the do/while
loop from ext4fs_get_extent_block() does not select the
proper extent index structure.

For example, if we have:

ext_block->eh_depth = 1
ext_block->eh_entries = 1
fileblock = 0
index[0].ei_block = 0

the do/while loop will exit with i set to 0 and the
ext4fs_get_extent_block() function will return 0, even if
there was a valid extent index structure following the
header.

Signed-off-by: Ionut Nicu 
Signed-off-by: Mathias Rulf

ext4fs: use EXT2_BLOCK_SIZE instead of fs->blksz

2014-01-20T15:09:40+00:00

Using fs->blksz in ext4fs_get_extent_block() is not
correct since fs->blksz is not initialized on the
read path. Use EXT2_BLOCK_SIZE() instead which will
produce the desired output.

Signed-off-by: Ionut Nicu 
Signed-off-by: Mathias Rulf

fs/ext4: fix calling put_ext4 with truncated offset

2014-01-20T15:09:38+00:00

Curently, we are using 32 bit multiplication to calculate the offset,
so the result will always be 32 bit.
This can silently cause file system corruption when performing a write
operation on partition larger than 4 GiB.

This patch address the issue by simply promoting the terms to 64 bit,
and let compilers decide how to do the multiplication efficiently.

Signed-off-by: Ma Haijun