Sponsored Content
Top Forums UNIX for Advanced & Expert Users Linux EXT3 superblock recovery Post 302230037 by era on Thursday 28th of August 2008 01:34:08 PM
Old 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

Help! Boot failure - corrupt superblock

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

How to corrupt a superblock?

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

superblock error

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

Linux HDD Recovery

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

linux system recovery after overriding connect() by "ld.so.preload"

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

Recovery of formatted ext3 partition

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

CentOS Error: Superblock

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

Superblock marked dirty

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

Linux bad superblock on /dev/mapper/VolGroup-lv_root

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
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)
All times are GMT -4. The time now is 02:32 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy