08-28-2008
Sounds like the journal is beyond recovery, but the filesystem as such can be recovered. The journal contains stuff since the last journal sync, which is usually not a major amount of data. So there will likely be some data loss to stuff that happened just before the crash, but it might be worth doing. (Perhaps you can take a clone of the raw disk with dd so you can revert if this operation turns sour after all.)
9 More Discussions You Might Find Interesting
1. Linux
Hi everyone,
OK, I've made a monumental fsck-up of my linux installation AND I did not backup my data properly (idiot!), so I'm really up the proverbial without a paddle here.
Basically the problem is I re-sized my /home partition (hda13) using Partition Magic 8.0, after doing so my mandrake... (0 Replies)
Discussion started by: alarmcall
0 Replies
2. Solaris
I need to corrupt a superblock of a mounted device in a soalris m/c and check recovery from an alternate superblock. How can this be done? (2 Replies)
Discussion started by: sujathan
2 Replies
3. Red Hat
can anybody help me to recovermy superblock , the recent power crash has done some stuff on my linux redhat 9 box .
when i startup the machine iam getting the following error:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it... (2 Replies)
Discussion started by: ppass
2 Replies
4. Filesystems, Disks and Memory
Hello,
I have my backup disks here because my server got hacked and we didn't like how liquidweb made the things. So we ask them to ship us the disk. They ran photorec and they got lots of .gz files from it. All accounts I would say. But 50% of them the .tar.gz files came corrupt. And is lefting... (2 Replies)
Discussion started by: asturmas
2 Replies
5. UNIX for Advanced & Expert Users
dear fellows;
i have used ld.so.preload file to override connect() function, dynamic library overriding, it did worked really fine ......
but i went on to struck in a situation ... within the overrided connect() i have used printf once to see IP and Port to whom the connect request is being... (1 Reply)
Discussion started by: mzeeshan
1 Replies
6. Filesystems, Disks and Memory
Hi!
I have a really big problem right now. I (accidently) formatted a ext3 partition with "mkfs.ext3 /dev/sda1". The problem is that I REALLY need some files from there. The partition had a size of about 4GB, after accidently formatting it, I accidently rewrote Grub on it :wall: I hope I didn't... (3 Replies)
Discussion started by: al0x
3 Replies
7. Linux
Hi Guys,
I really don't know where to put my query about this. And as a newbie, I think CentOS is closest to Ubuntu. Anyway, here's my dilemma. I have installed a VMWare - ESX 3.5 and installed CentOS 6 and cloned the CentOS 6. The first CentOS was working fine, when i cloned it, and the cloning... (2 Replies)
Discussion started by: init6_
2 Replies
8. UNIX for Advanced & Expert Users
Good morning!
I met a problem on a FS with AIX 5.3
It's not possible to mount the FS because of a dirty superblock.
I tried few things without success. I need your help to solve my problem guys. Do you have any idea please?
Thanks a lot
drp01,/home/root # mount /GSPRES/data
Replaying... (9 Replies)
Discussion started by: Castelior
9 Replies
9. Red Hat
Hi Friends . my linux try to start very slowly after give it this error:
mount: wrong fs type, bad option, bad superblock on /dev/mapper/VolGroup-lv_root,
missing codepage or helper program, or other error
in some cases useful info is found in syslog - try
dmesg : tail or so
Kernel panic... (3 Replies)
Discussion started by: blackjuan
3 Replies
LEARN ABOUT CENTOS
journal_abort
JOURNAL_ABORT(9) The Linux Journalling API JOURNAL_ABORT(9)
NAME
journal_abort - Shutdown the journal immediately.
SYNOPSIS
void journal_abort(journal_t * journal, int errno);
ARGUMENTS
journal
the journal to shutdown.
errno
an error number to record in the journal indicating the reason for the shutdown.
DESCRIPTION
Perform a complete, immediate shutdown of the ENTIRE journal (not of a single transaction). This operation cannot be undone without closing
and reopening the journal.
The journal_abort function is intended to support higher level error recovery mechanisms such as the ext2/ext3 remount-readonly error mode.
Journal abort has very specific semantics. Any existing dirty, unjournaled buffers in the main filesystem will still be written to disk by
bdflush, but the journaling mechanism will be suspended immediately and no further transaction commits will be honoured.
Any dirty, journaled buffers will be written back to disk without hitting the journal. Atomicity cannot be guaranteed on an aborted
filesystem, but we _do_ attempt to leave as much data as possible behind for fsck to use for cleanup.
Any attempt to get a new transaction handle on a journal which is in ABORT state will just result in an -EROFS error return. A journal_stop
on an existing handle will return -EIO if we have entered abort state during the update.
Recursive transactions are not disturbed by journal abort until the final journal_stop, which will receive the -EIO error.
Finally, the journal_abort call allows the caller to supply an errno which will be recorded (if possible) in the journal superblock. This
allows a client to record failure conditions in the middle of a transaction without having to complete the transaction to record the
failure to disk. ext3_error, for example, now uses this functionality.
Errors which originate from within the journaling layer will NOT supply an errno; a null errno implies that absolutely no further writes
are done to the journal (unless there are any already in progress).
AUTHORS
Roger Gammans <rgammans@computer-surgery.co.uk>
Author.
Stephen Tweedie <sct@redhat.com>
Author.
COPYRIGHT
Kernel Hackers Manual 3.10 June 2014 JOURNAL_ABORT(9)