EXT3 Reserve Space
2010-10-05 12:12:45 GMT
Hi All,
_______________________________________________ Ext3-users mailing list Ext3-users <at> redhat.com https://www.redhat.com/mailman/listinfo/ext3-users
Hi All,
_______________________________________________ Ext3-users mailing list Ext3-users <at> redhat.com https://www.redhat.com/mailman/listinfo/ext3-users
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
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 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
Hi,
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.inOn 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
Hi,
Please let us know the version of e2fsprogs you are using, and thenMuhammad 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?
>
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
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
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 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
* 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
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
* Ralf Gross <Ralf-Lists <at> ralfgross.de> hat geschrieben:> size: 175659
> ~ # ext3grep /dev/sda6 --inode 145601
> sectors: 352 (--> 1 indirect block).
> Direct Blocks: 325495 325496 325497 325498 325499 325500 325501 325502 325503 325504 325505 325506*** WARNING *** The following code snippet is meant to explain what you
> Indirect Block: 325507
>
> So I know that there is something left of the file, but I don't know how to get
> it back.
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
_______________________________________________ Ext3-users mailing list Ext3-users <at> redhat.com https://www.redhat.com/mailman/listinfo/ext3-users
RSS Feed2 | |
|---|---|
19 | |
5 | |
1 | |
1 | |
2 | |
8 | |
4 | |
1 | |
3 | |
1 | |
2 | |
9 | |
1 | |
21 | |
1 | |
20 | |
6 | |
11 | |
29 | |
14 | |
18 | |
18 | |
25 | |
22 | |
3 | |
6 | |
9 | |
11 | |
18 | |
8 | |
44 | |
43 | |
18 | |
20 | |
7 | |
7 | |
19 | |
9 | |
8 | |
72 | |
36 | |
44 | |
41 | |
63 | |
41 | |
50 | |
15 | |
45 | |
69 | |
31 | |
39 | |
70 | |
41 | |
28 | |
77 | |
36 | |
67 | |
15 | |
13 | |
35 | |
54 | |
27 | |
43 | |
29 | |
55 | |
48 | |
61 | |
43 | |
26 | |
35 | |
46 | |
54 | |
55 | |
47 | |
41 | |
45 | |
30 | |
88 | |
37 | |
23 | |
43 | |
29 | |
54 | |
21 | |
27 | |
13 | |
33 | |
45 | |
33 | |
36 | |
37 | |
72 | |
35 | |
36 | |
16 | |
23 | |
35 | |
15 | |
54 | |
54 | |
40 | |
69 | |
123 | |
64 | |
49 | |
57 | |
45 | |
50 | |
36 | |
74 | |
50 | |
120 | |
97 | |
99 | |
132 | |
146 | |
102 | |
133 | |
104 | |
174 | |
164 |