Muhammad Ammar | 5 Oct 2010 14:12
Picon

EXT3 Reserve Space

Hi All,



Whenever an EXT3 partition is created some space is reserved for super-user,  I used the mkfs.ext3 with option -m set to 0, but there is no effect it still reserve the space. How can i set the reserved-space to 0 or calculate the reserved-space in advance?

Any suggestion/idea?


Regards,
_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Lakshmipathi.G | 5 Oct 2010 15:00
Picon

Re: EXT3 Reserve Space

Hi,
Are you sure -m option is not working with mkfs.ext3? Can you verify it using tune2fs ?
If 5% is reserved already, you can use "tune2fs  -m 0 device" to modify it and check Reserved blocks count using "tune2fs -l device" command.

HTH

--
----
Cheers,
Lakshmipathi.G
FOSS Programmer.
www.giis.co.in


On Tue, Oct 5, 2010 at 5:42 PM, Muhammad Ammar <mammar <at> gmail.com> wrote:
Hi All,


Whenever an EXT3 partition is created some space is reserved for super-user,  I used the mkfs.ext3 with option -m set to 0, but there is no effect it still reserve the space. How can i set the reserved-space to 0 or calculate the reserved-space in advance?

Any suggestion/idea?


Regards,

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users




_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Eric Sandeen | 5 Oct 2010 15:43
Picon
Favicon
Gravatar

Re: EXT3 Reserve Space

Muhammad Ammar wrote:
> Hi All,
> 
> 
> Whenever an EXT3 partition is created some space is reserved for
> super-user,  I used the mkfs.ext3 with option -m set to 0, but there is
> no effect it still reserve the space. How can i set the reserved-space
> to 0 or calculate the reserved-space in advance?
> 
> Any suggestion/idea?
> 

Please let us know the version of e2fsprogs you are using, and then
show the commands you used which exhibited this problem.

Thanks,
-Eric
Muhammad Ammar | 5 Oct 2010 17:08
Picon

Re: EXT3 Reserve Space

Hi,


Yes, I checked it with both(mkfs.ext3 and tune3fs) on multiple systems but no effect. I also checked -m with multiple values(0, 1) but no effect

I am using Fedora 13.

Regards,



On Tue, Oct 5, 2010 at 6:00 PM, Lakshmipathi.G <lakshmipathi.g <at> gmail.com> wrote:
Hi,
Are you sure -m option is not working with mkfs.ext3? Can you verify it using tune2fs ?
If 5% is reserved already, you can use "tune2fs  -m 0 device" to modify it and check Reserved blocks count using "tune2fs -l device" command.

HTH

--
----
Cheers,
Lakshmipathi.G
FOSS Programmer.
www.giis.co.in


On Tue, Oct 5, 2010 at 5:42 PM, Muhammad Ammar <mammar <at> gmail.com> wrote:
Hi All,


Whenever an EXT3 partition is created some space is reserved for super-user,  I used the mkfs.ext3 with option -m set to 0, but there is no effect it still reserve the space. How can i set the reserved-space to 0 or calculate the reserved-space in advance?

Any suggestion/idea?


Regards,

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users





_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Muhammad Ammar | 5 Oct 2010 17:30
Picon

Re: EXT3 Reserve Space

Hi,



I think problem is solved. Actually i am checking the sizes in gparted and it is showing wrong value for 'USED' field.

Now i check the sizes using df and it shows correct sizes.

The version of e2fsprogs is:

e2fsprogs-1.41.10-6.fc13.i686

I used the following command to create an ext3 file system

mkfs.ext3 -m 0 /dev/sda2


Thanks to all of you for your time and sorry for confusion.


Regards,

On Tue, Oct 5, 2010 at 6:43 PM, Eric Sandeen <sandeen <at> redhat.com> wrote:
Muhammad Ammar wrote:
> Hi All,
>
>
> Whenever an EXT3 partition is created some space is reserved for
> super-user,  I used the mkfs.ext3 with option -m set to 0, but there is
> no effect it still reserve the space. How can i set the reserved-space
> to 0 or calculate the reserved-space in advance?
>
> Any suggestion/idea?
>

Please let us know the version of e2fsprogs you are using, and then
show the commands you used which exhibited this problem.

Thanks,
-Eric


_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Ralf Gross | 7 Oct 2010 14:44
Picon

file open -> disk full -> save -> file 0 byte

Hi,

a user had a file open when the disk ran full. He then saved the file
and now it's size is 0 byte (ext3). I don't know much more about this,
but he asked me if there is any chance to get the data of this file
back?

Ralf
Eric Sandeen | 7 Oct 2010 15:41
Picon
Favicon
Gravatar

Re: file open -> disk full -> save -> file 0 byte

Ralf Gross wrote:
> Hi,
> 
> a user had a file open when the disk ran full. He then saved the file
> and now it's size is 0 byte (ext3). I don't know much more about this,
> but he asked me if there is any chance to get the data of this file
> back?

I'm not sure how that happens; writes to the file should have hit ENOSPC;
ext3 doesn't even have delalloc to worry about so.

Did the application check the write return value?

(or maybe it was mmap writes, and since ext3 has no pg_mkwrite, it'd
just get lost, unfortunately...)

-Eric

> Ralf
Ralf Gross | 7 Oct 2010 15:52
Picon

Re: file open -> disk full -> save -> file 0 byte

Ralf Gross schrieb:
> Hi,
> 
> a user had a file open when the disk ran full. He then saved the file
> and now it's size is 0 byte (ext3). I don't know much more about this,
> but he asked me if there is any chance to get the data of this file
> back?

ext3grep /dev/sda6 --restore-file  path/to/file

restored only the 0 byte version but I found something with ext3grep. The user
remembered that the string "static void Associate_cluster" is part of the file.

~ # ext3grep /dev/sda6 --search "static void Associate_cluster"
Running ext3grep version 0.10.1
Number of groups: 53
Minimum / maximum journal block: 932 / 34660
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be
from 1286405586 = Thu Oct  7 00:53:06 2010
Number of descriptors in journal: 24920; min / max sequence numbers:
63706 / 72291
Blocks containing "static void Associate_cluster": 325515 (allocated)
904535 915577 1428545

I can get some further output with 'ext3grep /dev/sda6 --block 325515'

~ # ext3grep /dev/sda6 --block 325515
Running ext3grep version 0.10.1
No --ls used; implying --print.

Number of groups: 53
Minimum / maximum journal block: 932 / 34660
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1286405586 = Thu Oct  7 00:53:06 2010
Number of descriptors in journal: 24920; min / max sequence numbers: 63706 / 72291
Hex dump of block 325515:
0000 | 61 6e 65 4f 66 66 73 65 74 3b 0a 20 20 20 20 73 | aneOffset;.    s
0010 | 70 75 72 5f 70 6f 6c 79 5f 6d 65 73 73 2e 63 30 | pur_poly_mess.c0
[....]
0fd0 | 5f 48 6f 73 74 49 66 5f 74 20 2a 68 6f 73 74 49 | _HostIf_t *hostI
0fe0 | 66 2c 20 64 6f 75 62 6c 65 20 2a 56 61 6c 75 65 | f, double *Value
0ff0 | 4c 69 73 74 2c 20 69 6e 74 20 2a 56 61 6c 75 65 | List, int *Value

~ # ext3grep /dev/sda6 --search-inode 325515
Running ext3grep version 0.10.1
Number of groups: 53
Minimum / maximum journal block: 932 / 34660
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1286405586 = Thu Oct  7 00:53:06 2010
Number of descriptors in journal: 24920; min / max sequence numbers: 63706 / 72291
Inodes refering to block 325515: 145601

~ # ext3grep /dev/sda6 --inode 145601
Running ext3grep version 0.10.1
No --ls used; implying --print.

Number of groups: 53
Minimum / maximum journal block: 932 / 34660
Loading journal descriptors... sorting... done
The oldest inode block that is still in the journal, appears to be from 1286405586 = Thu Oct  7 00:53:06 2010
Number of descriptors in journal: 24920; min / max sequence numbers: 63706 / 72291

Hex dump of inode 145601:
0000 | ed 81 e8 03 2b ae 02 00 61 69 9b 4c ee c2 ad 4c | ....+...ai.L...L
0010 | 0e a8 7e 49 00 00 00 00 e8 03 01 00 60 01 00 00 | ..~I........`...
0020 | 00 00 00 00 00 00 00 00 77 f7 04 00 78 f7 04 00 | ........w...x...
0030 | 79 f7 04 00 7a f7 04 00 7b f7 04 00 7c f7 04 00 | y...z...{...|...
0040 | 7d f7 04 00 7e f7 04 00 7f f7 04 00 80 f7 04 00 | }...~...........
0050 | 81 f7 04 00 82 f7 04 00 83 f7 04 00 00 00 00 00 | ................
0060 | 00 00 00 00 f2 97 92 a7 00 00 00 00 00 00 00 00 | ................
0070 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................

Inode is Allocated
Group: 9
Generation Id: 2811402226
uid / gid: 1000 / 1000
mode: rrwxr-xr-x
size: 175659
num of links: 1
sectors: 352 (--> 1 indirect block).

Inode Times:
Accessed:       1285253473 = Thu Sep 23 16:51:13 2010
File Modified:  1286456046 = Thu Oct  7 14:54:06 2010
Inode Modified: 1233037326 = Tue Jan 27 07:22:06 2009
Deletion time:  0

Direct Blocks: 325495 325496 325497 325498 325499 325500 325501 325502 325503 325504 325505 325506
Indirect Block: 325507

So I know that there is something left of the file, but I don't know how to get
it back.

Ralf
Bodo Thiesen | 8 Oct 2010 15:10
Picon
Picon

Re: file open -> disk full -> save -> file 0 byte

* Ralf Gross <Ralf-Lists <at> ralfgross.de> hat geschrieben:

> ~ # ext3grep /dev/sda6 --inode 145601
> size: 175659
> sectors: 352 (--> 1 indirect block).
> Direct Blocks: 325495 325496 325497 325498 325499 325500 325501 325502 325503 325504 325505 325506
> Indirect Block: 325507
> 
> So I know that there is something left of the file, but I don't know how to get
> it back.

*** WARNING *** The following code snippet is meant to explain what you
could do. Please don't stop using your brain. ;)

*** BEGIN SNIPPET ***

#! /bin/sh

DEV=/dev/sda6
BS=4096
# This may be 2048 or 1024 - whatever cluster size your ext2
# file system uses

# Recover the first 12 clusters (the direct clusters)
dd if=$DEV bs=$BS of=/ramfs/restored.data skip=325495 count=12

# Get the indirect cluster
dd if=$DEV bs=$BS of=/ramfs/restored.ind skip=325507 count=1

# And dump it's content decimally ...
hexdump -e '4/4 "%10i " "\n"' /ramfs/restored.ind
# you should get an output like
# 325508 325509 325510 325511
# 325512 [...]
# Check, that the numbers are one bigger than the previous ones.

# Recover the following parts of the file (assuming, that the first
# number is the 325508 and that there are 5 countiguous numbers.
# The 12 comes from the previous skip argument
dd if=$DEV bs=$BS of=/ramfs/restored.data skip=325508 seek=12 count=5

# If there is a jump in the numbers printed by hexdump, continue with
# the next cluster chain (17 = 12 + 5 - it's just the sum of clustes
# already written to the file):
dd if=$DEV bs=$BS of=/ramfs/restored.data
skip=$whatever_number_comes_now seek=17 count=$length_of_chain

# Repeat the last step until you are done.

*** END SNIPPET ***

After you are done, check the file and then copy it over to the file
system so your user can continue to work on it again. And tell that user
that he should stop using the application he was using all together.
Overwriting a file with updated content is not state of the art for at
least two decades. The old file content has to be saved in a backup file
first or the old file could just be renamed. Every software I use does it
either way. This way your user wouldn't have had this problem in the first
place (just take the backup file and throw away the last 20 minutes of
work - recovery takes longer anyways ...). Alternatively: Think about a
proper daily (or even hourly) backup plan.

Regards, Bodo
Stephen Samuel | 8 Oct 2010 22:34

Re: file open -> disk full -> save -> file 0 byte

a slightly easier way of going through the indirect block...
recovered=12
for i in `hexdump -e '4/4 "%10i " "\n"' /ramfs/restored.ind` ; do
        if [[ "$i" -ne 0 ]] ; then
                dd if=$DEV bs=$BS of=/ramfs/restored.ind skip=$i seek=$((recovered++))  count=1
        fi
done

However, if the inode in question still exists, then I'd be inclined to suggest that you mount the filesystem
(readonly preferably), and then hunt for the inode.... let the filesystem do the heavy lifting for you.

find /mount/recovered -inum 145601 -print

or, even better yet:

cp ` find /mount/recovered -inum 145601 -print` recovered-file


On Fri, Oct 8, 2010 at 6:10 AM, Bodo Thiesen <bothie <at> gmx.de> wrote:
* Ralf Gross <Ralf-Lists <at> ralfgross.de> hat geschrieben:

> ~ # ext3grep /dev/sda6 --inode 145601
> size: 175659
> sectors: 352 (--> 1 indirect block).
> Direct Blocks: 325495 325496 325497 325498 325499 325500 325501 325502 325503 325504 325505 325506
> Indirect Block: 325507
>
> So I know that there is something left of the file, but I don't know how to get
> it back.

*** WARNING *** The following code snippet is meant to explain what you
could do. Please don't stop using your brain. ;)

*** BEGIN SNIPPET ***

#! /bin/sh

DEV=/dev/sda6
BS=4096
# This may be 2048 or 1024 - whatever cluster size your ext2
# file system uses

# Recover the first 12 clusters (the direct clusters)
dd if=$DEV bs=$BS of=/ramfs/restored.data skip=325495 count=12

# Get the indirect cluster
dd if=$DEV bs=$BS of=/ramfs/restored.ind skip=325507 count=1

# And dump it's content decimally ...
hexdump -e '4/4 "%10i " "\n"' /ramfs/restored.ind
# you should get an output like
# 325508 325509 325510 325511
# 325512 [...]
# Check, that the numbers are one bigger than the previous ones.

# Recover the following parts of the file (assuming, that the first
# number is the 325508 and that there are 5 countiguous numbers.
# The 12 comes from the previous skip argument
dd if=$DEV bs=$BS of=/ramfs/restored.data skip=325508 seek=12 count=5

# If there is a jump in the numbers printed by hexdump, continue with
# the next cluster chain (17 = 12 + 5 - it's just the sum of clustes
# already written to the file):
dd if=$DEV bs=$BS of=/ramfs/restored.data
skip=$whatever_number_comes_now seek=17 count=$length_of_chain

# Repeat the last step until you are done.

*** END SNIPPET ***

After you are done, check the file and then copy it over to the file
system so your user can continue to work on it again. And tell that user
that he should stop using the application he was using all together.
Overwriting a file with updated content is not state of the art for at
least two decades. The old file content has to be saved in a backup file
first or the old file could just be renamed. Every software I use does it
either way. This way your user wouldn't have had this problem in the first
place (just take the backup file and throw away the last 20 minutes of
work - recovery takes longer anyways ...). Alternatively: Think about a
proper daily (or even hourly) backup plan.

Regards, Bodo

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users



--
Stephen Samuel http://www.bcgreen.com  Software, like love,
778-861-7641                              grows when you give it away
_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Gmane