The problems you're having sound far more extensive than what I'd expect from mere loss of power (even during fairly heavy write activity) on a device. I have to wonder if you're really having more problems at the interface/driver level, or a corrupted partition table or something of that sort.
From the sounds of things you may have exacerbated the problem further with all the thrashing around you've done while trying to fix the issue.
I don't know if we can help with this case but don't give up yet.
For the future I'd suggest that you learn the following technique:
When you have trouble with a drive under Linux or UNIX you can usually use dd
to make a bit-image copy of the whole device to some other location. Find a drive that's at least as large as the one in question and try a command like: dd if=$PROBLEMATIC of=$TARGET bs=4M
... be very careful about the if (input file) and of (output file) directives. Leave that run. It's a good idea to run tail -f /var/log/messages &
(or possible variant as appropriate to your /etc/syslog.conf) ... either do that in the background or in another window. There are enhanced versions of dd
which can handle retries and continuing past bad blocks more robustly (sdd
is a name that comes to mind). But try just using the stock GNU dd
command at first.
You can make such a copy of the whole device (/dev/sdd, for example) or just the partition (/dev/sdd1). If you get "short read or similar errors then it suggests that either the device has physical errors preventing reads past certain cylinders or, in the case of a partition, that the partition table is mangled in some way. You can even make two different dd
images ... one of each.
Here's the trick: do all your fsck
and mount
attempts, and use your various other recovery tools such as TCT (The Coroner's Toolkit) on the copied image!
This minimizes the time spent running the drive (which is possibly degrading at the hardware level as you operate it) and minimizes the impact of failed and possibly misguided recovery attempts. (In some situations you make one image, then another based on that and always operate on the tertiary image ... depends on how much the data is worth).
I personally suggest that you run something like hexdump
or strings
to read through the image ... just let it scroll past for a long time and look for plain text that looks like it might be fragments of your data. I have used grep
to recover useful (textual) data from otherwise completely mangled filesystems. In case I'm not suggesting it as data recovery heroics ... but as a sanity check. If you scroll through 10s of megabytes or a few gigabytes of data and don't see any recognizable text ... then you probably have a hopeless case or you've done something very wrong (were you really careful about those if= and of= options?).
I don't know if any of this will help you with the current effort. But learn these tricks now and they will definitely make your next foray into data recovery much less scary. (Yes, practice on a healthy system once or twice --- go use a hex editor and try adding your own creative corruption here and there --- to the COPY of course! Then try fix it).
Oh, and this is a really good time to review your backup and data recovery plans and procedures (or provide better advice to your customer/colleague/client/friend/whatever).
By default, ext2 and its successors reserve 5% of the filesystem for use by the root user. This reduces fragmentation, and makes it less likely that the administrator or any root-owned daemons will be left with no space to work in.
These reserved blocks prevent programs not running as root from filling your disk.
Whether these considerations justify the loss of capacity depends on what the filesystem is used for.
The 5% amount was set in the 1980s when disks were much smaller, but was just left as-is. Nowadays 1% is probably enough for system stability.
The reservation can be changed using the -m
option of the tune2fs
command:
tune2fs -m 0 /dev/sda1
This will set the reserved blocks percentage to 0% (0 blocks).
To get the current value (among others), use the command :
tune2fs -l <device>
Best Answer
well with some experiment i found the answer,
I had used
mke2fs /dev/mmcblk0p2
command to format the partition. And after that if i mount/dev/mmcblk0p2
on the/media/emmcrfs
mount spits message that it is mounting file system without journal.when i used
mkfs.ext4 /dev/mmcblk0p2
command to format the partition and then mount/dev/mmcblk0p2
i see mount giving message that it is mounting file system with journal. For exact message see below commandSo when i googled it i found that
mke2fs
utility refers/etc/mke2fs.conf
file for different options. if mke2fs is not given any argument it takes parameters from[defaults]
from the/etc/mke2fs.conf
and these[defaults]
parameters doesn't have journal option.When i use command
mkfs.ext4
it internally callsmke2fs
withext4
as parameter and because of whichmke2fs
refers parameters for[ext4]
in the/etc/mke2fs.conf
. In my case[ext4]
contains the journaling option so it creates journal.Hope it helps someone having same question as me :)