All of lore.kernel.org
 help / color / mirror / Atom feed
From: supersud501 <supersud501@yahoo.de>
To: Theodore Tso <tytso@MIT.EDU>
Cc: Eric Sandeen <sandeen@redhat.com>, linux-ext4@vger.kernel.org
Subject: Re: e2fsck (git) on ext4: unsupported feature(s): huge_file
Date: Wed, 09 Apr 2008 19:53:42 +0200	[thread overview]
Message-ID: <47FD02A6.9090708@yahoo.de> (raw)
In-Reply-To: <20080409161117.GB26924@mit.edu>

Theodore Tso wrote:
> 
> That patch which I just sent out passes the regression test suite, but
> it hasn't been extensively tested for actual *huge* files.
> (Specifically, files with the EXT4_HUGE_FILE_FL because they are
> larger than 2TB and so i_blocks had to be specified in units of
> filesystem blocksize, instead of units of 512 bytes.)
> 
> If you could apply the patch I just sent out and then run "e2fsck -nf
> /dev/sdXXX" and let me know you get, that would be much appreciated.
> 

I'll do when the patch arrives in git (or where do i get it from?)

> In answer to question of how to determine if you actually *have* any
> large files, the simplest thing to do is to use debugfs to temporarily
> remove huge_file feature:
> 
> debugfs -w /dev/sdXXX               <------- disable the huge_file feature
> debugfs: features ^huge_file
> debugfs: quit
> 
> e2fsck -nf /dev/sdXXX
> 
> debugfs -w /dev/sdXXX               <------- re-enable the huge_file feature
> debugfs: features huge_file
> debugfs: quit
> 
> If you see error messages about i_blocks values being wrong (with the
> huge_file feature disabled), then the inodes that are referenced are
> the ones that have the huge_file flag set.
> 

Yeah, i'm getting some (~80) errors about i blocks being wrong (besides 
errors that a fast symlink has extents_fl set), and the error is always 
from the type: "i_blocks is x, should be x+8", so it always wants to add 
8 to the existing number. is this the mentioned miscalculation?

however, as i read in the mail from eric, i didn't know that there is a 
difference between "large" and "huge" files and apparently meant "large" 
(>2gb) files. i've got no "huge" (~2TB) files on my drive (and never had).

so i wonder why the flag is set on my drive and if the i_blocks errors i 
get are because of some miscalculation (which shouldn't happen, because 
i have no huge files, right?) or really are some errors (but it's weird 
e2fsck wants to set them always to x+8). doesn't make much sense to me yet.

oh and: thanks for getting into my problem and trying to help me!


  reply	other threads:[~2008-04-09 18:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-08 17:58 e2fsck (git) on ext4: unsupported feature(s): huge_file supersud501
2008-04-08 18:36 ` Eric Sandeen
2008-04-08 19:45   ` supersud501
2008-04-08 21:00     ` Theodore Tso
2008-04-09  9:15       ` supersud501
2008-04-09 16:11         ` Theodore Tso
2008-04-09 17:53           ` supersud501 [this message]
2008-04-09 18:59             ` Theodore Tso
2008-04-09 19:23               ` supersud501
2008-04-09 17:56           ` supersud501
2008-04-09 18:12           ` supersud501
2008-04-09 19:06             ` Theodore Tso
2008-04-09 19:19               ` supersud501
2008-04-09 21:08                 ` Theodore Tso
2008-04-11 13:04                   ` Theodore Tso
2008-04-11 13:38                     ` supersud501
2008-04-09 15:50       ` [E2FSPROGS, PATCH] Add support for the HUGE_FILE feature Theodore Ts'o
2008-04-09 12:54     ` e2fsck (git) on ext4: unsupported feature(s): huge_file Eric Sandeen
2008-04-09 14:45   ` Calvin Walton
2008-04-09 14:52     ` supersud501
2008-04-09 16:09       ` Eric Sandeen
2008-04-08 18:37 ` Eric Sandeen
2008-04-08 22:40   ` Christian Kujau

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=47FD02A6.9090708@yahoo.de \
    --to=supersud501@yahoo.de \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@MIT.EDU \
    /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.