🚀 go-pugleaf

Jayasuthan (suthan@netscape.net) wrote:
: Hi,

: Lately I had a consider massive file corruption .. lucky that none
: critical file corrupted. I could restore from backup but before that I
: need some help. How can I clean up lost+found files.. < I don't want it
: >. Two thos corrupted files ... how can I remove went "rm" doesn't works. The corrupted file is in device format linux file under /dev/.

Here is an old post on this subject.  I haven't had an occasion to use
the technique described and disclaim any responsibility for whatever
happens when you use it.

---
Subject: Re: Removing files from /lost+found

>
>These will be corrupt, immuable, device inodes.  You can only get rid
>of them with a low-level filesystem editor (see previous posts on the
>topic) as chattr does not work on device inodes for non-existant
>devices.

The only way to really clear these is to boot up single user
mode with the disk unmounted (or mounted read-only if it's the
root filesystem). Make a list of the file (The #nnnn number is
the inode number, you can confirm this by doing ls -i) inodes
into a file. Edit the file so that it's a list of commands like

    clri <inode-number>

With with <inode-number> replaced by the inode number of
the file, of course. You can do this by...

    cd /lost+found ; ls -i | awk '{print $1}' | sed -e '1,$ s/^/clri /'
>script_file

Then run debugfs with the -w and -f option to clear the inodes.
When debugfs exits, run a full e2fsck. This should detect the now
unreferenced files from lost+found and remove them.

    debugfs -w -f script_file
    e2fsck -fvy /dev/...

I had a machine once that use to mangle the news spool once a
week (turned out to be memory problems). Anyway this proceedure
became second nature.

Oh yeah, almost forgot the disclaimer. What you are about to do
is serious black magic so anything you trash is your own
responsibly. :) Make sure to read up the man pages first.


: This problem cause under Kernel 2.2.0 ... hdparm -m8  is consider a
: dangerous option. Please watchout !

--
Clifford Kite <kite@inetport.com>                       Not a guru. (tm)
/* Microsoft is a great marketing organization.
 * It _has_ to be */

Jayasuthan (suthan@netscape.net) wrote:
: Thank You very much.... I think I have try this but let me try it again.
: The part which I don't understand is " clri ". Is this a program or
: something in debugfs ?

It's a debugfs command.

--
Clifford Kite <kite@inetport.com>                       Not a guru. (tm)

Thank You very much.... I think I have try this but let me try it again.
The part which I don't understand is " clri ". Is this a program or
something in debugfs ?

I will try it again and post on the result.

Thank You,

Clifford Kite wrote:
> 
> Jayasuthan (suthan@netscape.net) wrote:
> : Hi,
> 
> : Lately I had a consider massive file corruption .. lucky that none
> : critical file corrupted. I could restore from backup but before that I
> : need some help. How can I clean up lost+found files.. < I don't want it
> : >. Two thos corrupted files ... how can I remove went "rm" doesn't works. The corrupted file is in device format linux file under /dev/.
> 
> Here is an old post on this subject.  I haven't had an occasion to use
> the technique described and disclaim any responsibility for whatever
> happens when you use it.
> 
> ---
> Subject: Re: Removing files from /lost+found
> 
> >
> >These will be corrupt, immuable, device inodes.  You can only get rid
> >of them with a low-level filesystem editor (see previous posts on the
> >topic) as chattr does not work on device inodes for non-existant
> >devices.
> 
> The only way to really clear these is to boot up single user
> mode with the disk unmounted (or mounted read-only if it's the
> root filesystem). Make a list of the file (The #nnnn number is
> the inode number, you can confirm this by doing ls -i) inodes
> into a file. Edit the file so that it's a list of commands like
> 
>     clri <inode-number>
> 
> With with <inode-number> replaced by the inode number of
> the file, of course. You can do this by...
> 
>     cd /lost+found ; ls -i | awk '{print $1}' | sed -e '1,$ s/^/clri /'
> >script_file
> 
> Then run debugfs with the -w and -f option to clear the inodes.
> When debugfs exits, run a full e2fsck. This should detect the now
> unreferenced files from lost+found and remove them.
> 
>     debugfs -w -f script_file
>     e2fsck -fvy /dev/...
> 
> I had a machine once that use to mangle the news spool once a
> week (turned out to be memory problems). Anyway this proceedure
> became second nature.
> 
> Oh yeah, almost forgot the disclaimer. What you are about to do
> is serious black magic so anything you trash is your own
> responsibly. :) Make sure to read up the man pages first.
> 
> : This problem cause under Kernel 2.2.0 ... hdparm -m8  is consider a
> : dangerous option. Please watchout !
> 
> --
> Clifford Kite <kite@inetport.com>                       Not a guru. (tm)
> /* Microsoft is a great marketing organization.
>  * It _has_ to be */

Hi,

A very big thank for your  great information. I am very happy that I
didn't format my hard disk drive but recovery [ cleanup ] my corrupted
file. It's sucessful.

But the pipe command doesn't work as debugfs I manual add
debugfs: clri <154> 

^ something like this.

But the bad news is ... I was supprise how come went I cleanup inode on
/home disk ... /dev/** files get effected  during fsck. Well I was
debugging on wrong disk ! It was my backup system disk. 

I manage to cleanup those files. It really great expriences.. and very
cool.

Thank You,

Suthan