On Donnerstag, 1. September 2016 19:25:30 CEST you wrote:
On Donnerstag, 1. September 2016 16:08:51 CEST you wrote:
Hi Stefan,
applying patch [U-Boot,v4,06/13]ext4 and Michael Walles patch [U-Boot,v4,3/4]ext4, I'm now able to write into directories on ext4 fs from u-boot. However, when deleting a given file (i.e. when writing to an existing filename), u-boot crashes when ext4 extents are enabled.
Some debugging showd that blknr from 'read_allocated_block' function returns negative value. I can only guess, maybe its due to 64 bit values calculated from ee_start_hi and ee_start_lo entries in the ext4_extent structure.
When disabling extents in the ext4 fs, deleting a given file is working.
Hi Thomas,
U-boots ext4 implementation currently does not support 64bit or even 48bit block numbers, so this may be the cause.
Can you provide some information about your test setup?
You can use the debugsfs ext tool to gather some information about the problematic file. Just access the filesystem with:
/sbin/debugfs /dev/sda1 ; (or whatever your partion name is)
or
/sbin/debugfs /path/to/imagefile
debugfs supports commands like cd, stat, ls. stat gives you the block number list.
Kind regards,
Stefan
Hi Thomas,
short followup:
read_allocated_blocks returns either 0 or -1 in case of an error. Unfortunately, the return value is only checked for 0 equality in most/all? cases, and seemingly my patch series introduced some more occasions.
Now, what *should* read_allocated_blocks return in case of an error? Either:
- 0: a file block can never be allocated as block 0, as that is always in use by the superblock and/or the bootsector block.
- <0: Extents allow 48 bit block numbers. "Limiting" the return value to the positive half of int64_t for valid block numbers and and reserving negative values for error codes is fine.
I would go for negative error codes, as these are more expressive. Comments/ opinions welcome!
I will update the patch series for correct checking of read_allocated_blocks return values and fix all the other block number checks.
Anyway, it would be good to know why *exactly* read_allocated_blocks returns an error code in your case. Do you remember the exact negative value returned (there are -EINVAL and -ENOMEN, and many several unspecific uses of 0 and -1).
Can you provide a disk image of the failing file system?
Kind regards,
Stefan