All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.