headers
Bodo Thiesen | 1 Feb 2004 07:00
Picon
Picon

Ext3 and undeletion - A way how it could work.

Hello.

After reading some mails from mailing list archives and other sources, 
ext3 seems to having troubles in deleting files w/o destroying the data 
neccessary to undelete them. Ok, I know what journaling means, and in any 
way, the ext3 fs driver needs to keep track of which blocks have actually 
been marked as being free. But now my question: Who say, that this 
information must be stored in the original inode data? The answer is: Is 
isn't neccessary at all. Ok, how then?

My prescription:

1.1. We need a fixed inode, I'll refer to that as the "deletion inode" 
     here.
1.2. We need three blocks, whichs block numbers could be stored in the 
     super block. I'll refer to them as "deletion blocks" here.

Now, lets assume, a user enters rm foo.img where foo.img is a very big 
file. The steps, the ext3fs driver currently does is (IIRC, at least):

2.1. Link the inode to a special list of "inodes to delete". -- no change 
     here.
2.2. Check, if any inode is being delete in the moment. If not start it 
     now (go on with 3.1.). -- no change here.

Actual deletion: (That action initiated in step 2.2.)

Here, the procedure will completely changed:

3.1. Copy the inode (the 128 bytes, not the conten of the file ;-) to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nigel Metheringham | 2 Feb 2004 18:10
Picon

Re: Filesystem returned to state of six months ago after fsck

[Copy to list - original accidently only sent to Boris]

On Sat, 2004-01-31 at 06:19, Boris Lenhard wrote:
> Recently our sysadm accidentally powercycled our server (RedHat8)
> after 198 days of uptime, and upon boot it insisted on checking one
> partition (/dev/sda7) in our RAID. When it was done, the files were in
> the state of August 23 last year, with anything newer either gone or
> invisible. I guess something went wrong with journaling data. What can
> I do to restore the current state (except restore from backup, which
> is an unfavorable option on Saturday morning) ?.

This really can't be an ext3 fault.

It sounds more like a disk went offline in a RAID1 pair and then the
disks swapped over on the restart (or the disk that been offline came
online and the other disk was synced to it).  If you have 2 (sets of) 
disks running in the current RAID set and they are synced I'd say you
need your backups.   Otherwise its a case of working out how to get the
right half of the RAID1 set up and then fixing from there.

        Nigel.
--

-- 
[ Nigel Metheringham           Nigel.Metheringham <at> InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
Permalink | Reply | 1 comment |
headers
Matthew Galgoci | 2 Feb 2004 18:48
Picon
Favicon
Gravatar

Re: Filesystem returned to state of six months ago after fsck

On Mon, 2 Feb 2004, Nigel Metheringham wrote:

> [Copy to list - original accidently only sent to Boris]
> 
> On Sat, 2004-01-31 at 06:19, Boris Lenhard wrote:
> > Recently our sysadm accidentally powercycled our server (RedHat8)
> > after 198 days of uptime, and upon boot it insisted on checking one
> > partition (/dev/sda7) in our RAID. When it was done, the files were in
> > the state of August 23 last year, with anything newer either gone or
> > invisible. I guess something went wrong with journaling data. What can
> > I do to restore the current state (except restore from backup, which
> > is an unfavorable option on Saturday morning) ?.
> 
> This really can't be an ext3 fault.
> 
> It sounds more like a disk went offline in a RAID1 pair and then the
> disks swapped over on the restart (or the disk that been offline came
> online and the other disk was synced to it).  If you have 2 (sets of) 
> disks running in the current RAID set and they are synced I'd say you
> need your backups.   Otherwise its a case of working out how to get the
> right half of the RAID1 set up and then fixing from there.

It's also possible that there was a doublly mounted filesystem. For example,
/dev/sda7 was mounted as /var/ on top of an already mounted /dev/md6. Processes
have the namespace of /dev/sda7 and all the new data gets written there. When
the system reboots the raid1 array is unpinned and reconstructed, and possibly
mounted only once (/dev/sda7 may or may not be mounted), and presto, once the
reconstruction finishes you have your original data.

I've actually seen this happen :\
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Berg | 3 Feb 2004 18:34

(no subject)


--

-- 
Matthew Berg <galt <at> gothpoodle.com>
Permalink | Reply | 0 comments |
headers
Scot Mc Pherson | 3 Feb 2004 22:51
Picon
Favicon

e2undel for ext3

Is there an ext3 version of this? Something in ext3 makes e2undel unable to 
recover unlinked inodes. I just deleted something, umounted the drive to 
preserve the state. I used e2undel to look for stuff to recover and it found 
0 deleted files.

I have been using e2undel for quite a while with great success and I know hwo 
to use it, but it seems to not be able to recover stuff on ext3. Is there a 
difference in the superblock structure the way ext3 unlinks files? I am sure 
they are there still obviously.

I don't "need" these files, but I would be VERY upset to loose them.

--

-- 
Scot Mc Pherson <scot <at> linuxfromscratch.org>
http://linuxfromscratch.org/~scot/
Usenet Server Admin, IRCop, RPM Maintainer
ICQ: 342949
AIM: ScotLFS
MSN: behomet <at> earthlink.net
Permalink | Reply | 3 comments |
headers
Mike Fedyk | 3 Feb 2004 22:56

Re: e2undel for ext3

On Tue, Feb 03, 2004 at 04:51:43PM -0500, Scot Mc Pherson wrote:
> I don't "need" these files, but I would be VERY upset to loose them.

You'll have to go over your drive block by block to reconstruct your data
then.

Ext3 truncates before unlinking because of the journaling.

I'd love it if someone found a way to allow undelete in ext3.  Any ideas?

Other than that, you should look at a userspace solution like libtrash.

Mike
Permalink | Reply | 1 comment |
headers
Andreas Dilger | 3 Feb 2004 23:25

Re: e2undel for ext3

On Feb 03, 2004  16:51 -0500, Scot Mc Pherson wrote:
> Is there an ext3 version of this? Something in ext3 makes e2undel unable to 
> recover unlinked inodes. I just deleted something, umounted the drive to 
> preserve the state. I used e2undel to look for stuff to recover and it found 
> 0 deleted files.
> 
> I have been using e2undel for quite a while with great success and I know hwo 
> to use it, but it seems to not be able to recover stuff on ext3. Is there a 
> difference in the superblock structure the way ext3 unlinks files? I am sure 
> they are there still obviously.

Unfortunately, yes, there is a difference in the way that ext3 operates that
prevents e2undel from working.  This is required to ensure that if ext3
crashes during an unlink that you don't lose space in the filesystem, because
there is no full fsck run at boot.

> I don't "need" these files, but I would be VERY upset to loose them.

Depending on the content/size of the files, you may be able to recover them
by using e.g. "strings -tx /dev/foo" to search for keywords if text files
were deleted, or possibly some custom code to search for binary values like
magic numbers.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Permalink | Reply | 0 comments |
headers
Andreas Dilger | 3 Feb 2004 23:35

Re: e2undel for ext3

On Feb 03, 2004  13:56 -0800, Mike Fedyk wrote:
> I'd love it if someone found a way to allow undelete in ext3.  Any ideas?

Yes, the best solution is to do the following:
- before truncating the file, walk all of the direct/indirect/tindirect blocks
  and count all of the bitmaps and group descriptor blocks that will be
  dirtied when the file is unlinked (this isn't a perf hit, since you will
  need to read these at some point anyways during the unlink, and bonus points
  if you read the {d,t,}indirect blocks many at once instead of one at a
  time like it does now)
- see if you can start a single transaction that is big enough to hold all
  of these blocks (likely yes, up to 8GB file size or larger if you create
  a larger journal on the disk)
- if you can start a single large transaction simply free all of the file
  blocks and mark the inode deleted like ext2 does, without zeroing any
  of the direct/indirect blocks or i_blocks or i_size
- now e2undel can get all of the block information back like it could with
  ext2
- this has the added benefit of not writing out any of the indirect blocks
  (1/1024 of the total file size) so you reduce your writes by 95% and
  speed up unlinking dramatically

So, it's a win-win situation.  Much faster truncating, and undeletion.

If you can't start the large transaction you could always fall back to the
old "zero indirect blocks and grow transaction when possible" method that
ext3 uses now.

Cheers, Andreas
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Berg | 4 Feb 2004 18:51

Odd result of increasing journal size?

[NOTE: I apologize in advance if this shows up as a duplicate.  I sent
it once by accident from the wrong account, so the message has been
waiting moderation.  If the moderator reads the list, hopefully they'll
notice I already posted :)]

I have a number of machines which are used for mail storage.  We've had
issues with sporadic slow connections to the machine, seemingly blocking
on I/O.

After running some tests it seemed as if we might be filling the
journal.  In some synthetic testing we did, increasing journal size
eliminated the spikes we saw at regular intervals with a large amount of
simultaneous reading and writing.

This weekend we increased journal size from 32MB to 256MB on a group of
machines.  There was one with the following configuration:

        2 x P3/667
        256MB
        ServeRAID 4L (16MB cache, writethrough)
        5 x 18GB 10k Ultra160 (RAID5, 8KB stripe)
        Red Hat 7.2 w/ kernel 2.4.20-18.7

The rest are:

        2 x Xeon/2.4
        1024MB
        ServeRAID 6i (128MB cache, writethrough)
        5 x 36GB 15k Ultra320 (RAID5EE, 8KB stripe)
        Red Hat 7.2 w/ kernel 2.4.20-24.7 (addl path: ips 6.10 driver)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Knight | 5 Feb 2004 00:59
Picon
Picon

RAID 0 Problems - resubmission as subsriber

Can some one help me with a ext3 file sys problem??

I have a raid 0 array that was not shut down properly due to bad 
contacts in a removable drive bay.
It consists of two 80Gb drives.
I can create /dev/md0 ok.
but if fails during mount.

When I run: fsck -n /dev/md0
it reports the following:

fsck 1.32
e2fsck 1.32
SuperBlock has a bad ext3 journal (inode 8)
clear? no

fsck.ext2: illegal inode number while checking ext3 journal for /dev/md0

I guess my question is, will clearing the bad Inode ruin my chances of 
recovering this drive.

Also is anyone able to advise me on a very good source of information on 
the ext3 file system.
EG. Its layout on a physical disk. and how it works.
and also some sort of disk monitor for i386 red hat 9.

This array was originally running on a mandrake 8.2 system but that 
system caused segmentation faults when trying to run fsck. so they are 
now running under Red Hat 9.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane