From: "Brüns, Stefan" <Stefan.Bruens@rwth-aachen.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] ext4 delete file fails when ext4 extents enabled in filesystem
Date: Fri, 2 Sep 2016 11:43:17 +0000 [thread overview]
Message-ID: <8673131.TQAZLALiPZ@sbruens-linux> (raw)
In-Reply-To: <210402466.2eHZBqhtK4@sbruens-linux>
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
next prev parent reply other threads:[~2016-09-02 11:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 16:08 [U-Boot] ext4 delete file fails when ext4 extents enabled in filesystem Thomas Schaefer
[not found] ` <210402466.2eHZBqhtK4@sbruens-linux>
2016-09-02 11:43 ` Brüns, Stefan [this message]
2016-09-02 14:51 ` Thomas Schaefer
2016-09-05 14:37 ` Brüns, Stefan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8673131.TQAZLALiPZ@sbruens-linux \
--to=stefan.bruens@rwth-aachen.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox