Re: Undeletion utililty for ext3/4

On Thu, 30 Apr 2009, Number9652 wrote:
> I have recently released a project on sourceforge 
> ( http://extundelete.sourceforge.net ) that can undelete a file from an 
> ext3 or ext4 partition.  It uses code from ext3grep to parse 
> command-line options, and uses libext2fs to read the partitions.
> Instead of reading the entire partition, as ext3grep does, it reads 
> only the journal file and is able to restore a deleted file from the 
> information there and in (possibly deleted) directory blocks.  I hope it 
> is of some use.

Thanks - I've added this to the collection of ext2/3 undeletion tools in 
the wiki: http://ext4.wiki.kernel.org/index.php/Undeletion

Christian.
--

-- 
Bruce Schneier once broke AES using nothing but six feet of rusty barbed wire,
a toothpick, and the front axle from a 1962 Ford Falcon.

Re: Undeletion utililty for ext3/4

On Saturday 02 May 2009 19:00:14 ext3-users-request <at> redhat.com wrote:
>  have recently released a project on sourceforge
>
> > ( http://extundelete.sourceforge.net ) that can undelete a file from an
> > ext3 or ext4 partition.  It uses code from ext3grep to parse
> > command-line options, and uses libext2fs to read the partitions.
> > Instead of reading the entire partition, as ext3grep does, it reads
> > only the journal file and is able to restore a deleted file from the
> > information there and in (possibly deleted) directory blocks.  I hope it
> > is of some use.
>
> Thanks - I've added this to the collection of ext2/3 undeletion tools in
> the wiki: http://ext4.wiki.kernel.org/index.php/Undeletion

Look good. Never had much luck with ext3grep.

However, cannot compile it. Has these huge hex constants that will not fit 
usual long types. Does this code need a 64-bit kernel or can I do something to 
the #defined I64 type to get this to compile?

Re: Undeletion utililty for ext3/4

David Baron wrote:
> On Saturday 02 May 2009 19:00:14 ext3-users-request <at> redhat.com wrote:
>>  have recently released a project on sourceforge
>>
>>> ( http://extundelete.sourceforge.net ) that can undelete a file from an
>>> ext3 or ext4 partition.  It uses code from ext3grep to parse
>>> command-line options, and uses libext2fs to read the partitions.
>>> Instead of reading the entire partition, as ext3grep does, it reads
>>> only the journal file and is able to restore a deleted file from the
>>> information there and in (possibly deleted) directory blocks.  I hope it
>>> is of some use.
>> Thanks - I've added this to the collection of ext2/3 undeletion tools in
>> the wiki: http://ext4.wiki.kernel.org/index.php/Undeletion
> 
> Look good. Never had much luck with ext3grep.
> 
> However, cannot compile it. Has these huge hex constants that will not fit 
> usual long types. Does this code need a 64-bit kernel or can I do something to 
> the #defined I64 type to get this to compile?

I haven't really looked over it in any detail, but try sticking a "ULL"
on the end of those constants.

-Eric

How to build a new root file system?

Hi,
I'm trying to create new root file system for my kernel.
How to do that? Any documentation links ?

I have spent some time with Linux From Scratch - but messed somewhere?
Should i process with LFS again ?

I'm trying to find a solution for question posted here.
http://www.linuxforums.org/forum/linux-kernel/144378-booting-custom-kernel-new-file-system-new-post.html
--

-- 
Cheers,
Lakshmipathi.G

[OT] Re: Undeletion utililty for ext3/4

On Thu, 30 Apr 2009, Number9652 wrote:
> I have recently released a project on sourceforge
> ( http://extundelete.sourceforge.net ) that can undelete a file from an 
> ext3 or ext4 partition.  It uses code from ext3grep to parse 
> command-line options, and uses libext2fs to read the partitions.

Hm, compiling with g++ 4.4 gave me a few compiling errors[0] - the patch 
attached "fixes" them, but when extundelete is actually used, it crashes:

# ./extundelete /dev/md0
Running extundelete version 0.0.3
extundelete: extundelete.cc:894: void load_super_block(struct_ext2_filsys*):
Assertion `(super_block.s_feature_compat & 0x0004)' failed.
Aborted

...but maybe that has been caused by the patch. Hm.

Christian.

[0] http://nerdbynature.de/bits/extundelete/
--

-- 
All infinite sets are countable -- by Bruce Schneier.

diff -Nrup extundelete-0.0.3/src/insertionops.cc extundelete-0.0.3.edited/src/insertionops.cc
--- extundelete-0.0.3/src/insertionops.cc	2009-04-28 20:17:32.000000000 +0200
+++ extundelete-0.0.3.edited/src/insertionops.cc	2009-05-03 12:54:14.000000000 +0200
 <at>  <at>  -8,6 +8,8  <at>  <at> 
 #include <ext2fs/ext2fs.h>
 #include "kernel-jbd.h"
 #include "undel.h"

Re: [OT] Re: Undeletion utililty for ext3/4

On May 03, 2009  10:03 -0700, Christian Kujau wrote:
> On Thu, 30 Apr 2009, Number9652 wrote:
> > I have recently released a project on sourceforge
> > ( http://extundelete.sourceforge.net ) that can undelete a file from an 
> > ext3 or ext4 partition.  It uses code from ext3grep to parse 
> > command-line options, and uses libext2fs to read the partitions.
> 
> Hm, compiling with g++ 4.4 gave me a few compiling errors[0] - the patch 
> attached "fixes" them, but when extundelete is actually used, it crashes:
> 
> # ./extundelete /dev/md0
> Running extundelete version 0.0.3
> extundelete: extundelete.cc:894: void load_super_block(struct_ext2_filsys*):
> Assertion `(super_block.s_feature_compat & 0x0004)' failed.
> Aborted
> 
> ...but maybe that has been caused by the patch. Hm.

This is probably due to a new ext4 feature.  Look at this line of the
code and see what feature it is checking for.

> Christian.
> 
> [0] http://nerdbynature.de/bits/extundelete/
> -- 
> All infinite sets are countable -- by Bruce Schneier.

> diff -Nrup extundelete-0.0.3/src/insertionops.cc extundelete-0.0.3.edited/src/insertionops.cc
> --- extundelete-0.0.3/src/insertionops.cc	2009-04-28 20:17:32.000000000 +0200
> +++ extundelete-0.0.3.edited/src/insertionops.cc	2009-05-03 12:54:14.000000000 +0200

Re: [OT] Undeletion utililty for ext3/4

On Sun, 3 May 2009, Andreas Dilger wrote:
> This is probably due to a new ext4 feature.  Look at this line of the
> code and see what feature it is checking for.

Hm, at extundelete.cc:894 we have:

  // File system must have a journal.
  assert((super_block.s_feature_compat & EXT3_FEATURE_COMPAT_HAS_JOURNAL));
  if ((super_block.s_feature_compat & EXT2_FEATURE_COMPAT_DIR_PREALLOC))
    std::cout << "WARNING: I don't know what EXT2_FEATURE_COMPAT_DIR_PREALLOC is.\n";

The EXT3_FEATURE_COMPAT_HAS_JOURNAL is a standard ext3/4 feature, not sure 
about the EXT2_FEATURE_COMPAT_DIR_PREALLOC thing.

Thanks for replying, Andreas - but I could imagine that this is better 
discussed on the extundelete lists - sorry for this noise.

Christian.
--

-- 
Bruce Schneier has found SHA-512 preimages of all these facts.

Re: File System Selection

Ramesh wrote:
> Hi All,
> 
> 
> I am developing a SD Block Driver.
> 
> As per old specification (SD Spec 2.0 ) Maximum size of SD memory
> card is 32 GB. - We used ext2 file system.
> 
> By referring the new Specification (SD Spec 3.0) SD memory card size
> is reached upto and including 2TB (Terra Byte) - Block size strictly
> limited to 512 only (as per specification).
> 
> My Questions.
> 
> 1. For 2TB disk with Block size 512, Which file system is preferred
> (ext3/ext4)

do you mean sector size of the block device, or block size of the
fileystem?  I guess it doesn't matter much either way, 2^32*512 is 2T.
Either ext3 or ext4 can handle this size, you'll probably need to make
your decision based on other factors.

> 2. In a 32 bit machine, If I installed the Fedora 10 ( having ext4),
> am I able to use it as effectively ( for the maximum disk/file size
> usage). To utilize 2TB or more size hard disk, is this allowable to
> use 32 bit machine with Ext4 fs?
> 

On a 32 bit machine you will be limited to 16T, this is actually a page

Some inode questions

When I first create /var I took all the defaults.  I have since decided
that, since it will hold a cyrus mail spool (each message is a file) I
should use something with more inodes.  I created a new (var2) partition
and formatted it with 
# mkfs.ext3 -T news /dev/mapper/turtle-var2_crypt
# news has inode_ratio = 4096

Then I mounted and rsync'd from my existing /var.
Afterwords, I get a report that seems to indicate I've used almost no
inodes.  It also shows more inodes than blocks; is there any way one
could need more than one inode/block?
# dumpe2fs -h /dev/mapper/turtle-var2_crypt
dumpe2fs 1.41.3 (12-Oct-2008)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          823219cf-30dc-42f9-ac96-1112bc7fe070
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index
filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              6291456
Block count:              6291199
Reserved block count:     314559
Free blocks:              5853517
Free inodes:              6291445

Re: Some inode questions

On May 05, 2009  11:40 -0700, Ross Boylan wrote:
> When I first create /var I took all the defaults.  I have since decided
> that, since it will hold a cyrus mail spool (each message is a file) I
> should use something with more inodes.  I created a new (var2) partition
> and formatted it with 
> # mkfs.ext3 -T news /dev/mapper/turtle-var2_crypt
> # news has inode_ratio = 4096
> 
> Then I mounted and rsync'd from my existing /var.
> Afterwords, I get a report that seems to indicate I've used almost no
> inodes.  It also shows more inodes than blocks; is there any way one
> could need more than one inode/block?

Hard links, or empty files...

> As I read this, 6291445 of 6291456 inodes are free, so 11 are in use.
> The comparable calculation on the origin file system shows about 8,500
> inodes in use.

Indeed, it seems your new filesystem is empty.  That said, the superblock
contents are not updated on disk while the filesystem is mounted.  I have
argued that since we are already computing the superblock totals and
storing them into the superblock it wouldn't be harmful to write the
superblock to disk occasionally in ext[34]_statfs() by calling at the end:

	ext[34]_commit_super(sb, es, 0);

I don't think there is currently anything in ext[34] that is writing
the superblock to disk at all, except mount and unmount.