headers
Keith Roberts | 5 Dec 2010 23:10
Favicon

Inode 196617 has imagic flag set

This is stopping my new Centos 5.5 installation from 
booting.

I have dropped into maintainance mode and run e2fsck without 
getting any errors. I used the -c option, and no bad blocks 
were found.

I've run another disk checker program called Vivard, from 
the Ultimate Boot CD disk. That completed without any errors 
as well.

So this is a mystery why I get this error at boot time.

Any ideas what's happening please?

Where can I find out more about ext3, such as inodes, dtime 
and imagic flag?

Kind Regards,

Keith Roberts

--

-- 
In theory, theory and practice are the same;
in practice they are not.

This email was sent from my laptop with Centos 5.5
Permalink | Reply | 5 comments |
headers
Ted Ts'o | 6 Dec 2010 03:24
Picon
Picon
Favicon
Gravatar

Re: Inode 196617 has imagic flag set

On Sun, Dec 05, 2010 at 10:10:38PM +0000, Keith Roberts wrote:
> This is stopping my new Centos 5.5 installation from booting.
> 
> I have dropped into maintainance mode and run e2fsck without getting
> any errors. I used the -c option, and no bad blocks were found.

That error "Inode ... has imagic flag set" is an e2fsck error.  Do you
have more than one file system on your system?  Maybe you checked the
one file system, and the error was on another file system.

That error very often means that part of your inode table has gotten
corrupted, since that flag should never get set during normal
operation.  (It was implemented for AFS file servers.)

	    	    		    	     - Ted
Permalink | Reply | 4 comments |
headers
Keith Roberts | 6 Dec 2010 14:07
Favicon

Re: Inode 196617 has imagic flag set

On Sun, 5 Dec 2010, Ted Ts'o wrote:

> To: Keith Roberts <keith <at> karsites.net>
> From: Ted Ts'o <tytso <at> mit.edu>
> Subject: Re: Inode 196617 has imagic flag set
> 
> On Sun, Dec 05, 2010 at 10:10:38PM +0000, Keith Roberts wrote:
>> This is stopping my new Centos 5.5 installation from booting.
>>
>> I have dropped into maintainance mode and run e2fsck without getting
>> any errors. I used the -c option, and no bad blocks were found.
>
> That error "Inode ... has imagic flag set" is an e2fsck error.  Do you
> have more than one file system on your system?  Maybe you checked the
> one file system, and the error was on another file system.

Absolutely spon on Ted!

I did have a USB stick plugged in, to boot my Kickstart file 
from. I also added another partition to the USB drive, also 
with a partition label called 'websites'. So I could upload 
my websites to my hosting provider from my laptop.

Maybe e2fsck was getting confused at having two partitions 
with the same partition label on the system?

So I renamed the partition on my USB drive, to my-websites.

+++
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ted Ts'o | 6 Dec 2010 14:27
Picon
Picon
Favicon
Gravatar

Re: Inode 196617 has imagic flag set

On Mon, Dec 06, 2010 at 01:07:38PM +0000, Keith Roberts wrote:
> 
> Maybe e2fsck was getting confused at having two partitions with the
> same partition label on the system?

Well, the blkid library, specifically, was getting confused.  E2fsck
uses the blkid library to map LABEL= and UUID= references to device
names.

One thing that you might do for devices that are always present (which
generally means you're not changing them in your /etc/fstab often) is
to use a UUID= reference instead.  They are definitely less convenient
than labels, but they are also much less likely to cause confusion by
having duplicately labelled file systems.

Granted, no one wants to *type* "mount
UUID=9e132c06-1fd0-4bbd-ad06-5995a8f45b26"; they'd much rather type
"mount LABEL=websites".  But if the only place the a
UUID=... specification shows up is in /etc/fstab, it might be worth
it.

Then you can just zap the label on file systems that you only plan to
reference via UUID, and then that reduces the chances for confusion in
the future.

Best regards,

> PS Are there any PDF docs that would give me an overview of the ext3
> FS, and how it works?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Roberts | 6 Dec 2010 15:20
Favicon

Re: Inode 196617 has imagic flag set

On Mon, 6 Dec 2010, Ted Ts'o wrote:

> To: Keith Roberts <keith <at> karsites.net>
> From: Ted Ts'o <tytso <at> mit.edu>
> Subject: Re: Inode 196617 has imagic flag set
> 
> On Mon, Dec 06, 2010 at 01:07:38PM +0000, Keith Roberts wrote:
>>
>> Maybe e2fsck was getting confused at having two partitions with the
>> same partition label on the system?
>
> Well, the blkid library, specifically, was getting confused.  E2fsck
> uses the blkid library to map LABEL= and UUID= references to device
> names.

What about if th blkid library was to report some sort of 
'duplicate label name' error, when it maps the devices to 
label names?

That would be a great help.

> One thing that you might do for devices that are always present (which
> generally means you're not changing them in your /etc/fstab often) is
> to use a UUID= reference instead.  They are definitely less convenient
> than labels, but they are also much less likely to cause confusion by
> having duplicately labelled file systems.
>
> Granted, no one wants to *type* "mount
> UUID=9e132c06-1fd0-4bbd-ad06-5995a8f45b26"; they'd much rather type
> "mount LABEL=websites".  But if the only place the a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ted Ts'o | 6 Dec 2010 16:46
Picon
Picon
Favicon
Gravatar

Re: Inode 196617 has imagic flag set

On Mon, Dec 06, 2010 at 02:20:24PM +0000, Keith Roberts wrote:
> 
> Can I set the UUID value, with some descriptive text,(something like
> a long label name), or is the UUID only system generated?

The UUID is a Universally Unique ID; it is a 128-byte number,
constructed using the rules specified by RFC 4122.  See:

	    http://www.ietf.org/rfc/rfc4122.txt

You can set the UUID to something else, although the only way I
suggest people make use of this functionality to use "tune2fs -U
random" after doing an image copy of a file system.  The whole point
of a UUID is that it should be universally unique, and humans are
notoriously bad at picking ID's that are truly unqiue.

> The first link in the list is interesting :)
> 
> I think the reason the USB has SO MANY errors on the FS is because I
> possibly unplugged it, before umounting it!
> 
> I understand that the umount command flushes any disk I/O buffers
> back to the drive?

Correct; I'd do a sync after the umount just to be absolutely sure,
though.  IIRC the umount doesn't wait until the USB stick has
acknowledged that it is done writing everything to flash.

	     	       	     	 	- Ted
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Kennedy | 6 Dec 2010 19:42
Picon

SQLite and ext3 journalling mode

Hi,

Are SQLite users that are worried about losing data that has been
committed (fsynced) better off setting data=journal than
data=ordered (or even data=writeback)?

The context is trying to reduce the number of writes to a flash
file-system without sacrificing data integrity in the event of a
power failure or OS crash.

Thanks,
Dan Kennedy.
Permalink | Reply | 8 comments |
headers
Ralf Hildebrandt | 6 Dec 2010 20:34
Picon
Favicon

Re: Squid and first-level subdirectories & second-level subdirectories on ext3/4

* Andreas Dilger <adilger <at> dilger.ca>:

> In ext3/4 the top-level inodes are spread around the filesystem, on the
> assumtion that something like /home or / is allocating trees of
> unrelated subdirectories at the top level, but that files within those
> subdirectories ARE related and should be allocated together.
> 
> Depending on how many files are in your cache, the 256 * {small files}
> is likely too big to fit into a single block group (32k inodes, 32k
> blocks) so you may want to consider marking the first level of
> subdirectories with the "TOPDIR" flag, that indicates the second-level
> (256) subdirs should also be spread around the disk.

How do I mark subdirectories with the "TOPDIR" flag?

--

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebrandt <at> charite.de | http://www.charite.de
	    

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Permalink | Reply | 1 comment |
headers
Ralf Hildebrandt | 6 Dec 2010 21:33
Picon
Favicon

Re: Squid and first-level subdirectories & second-level subdirectories on ext3/4

* Ralf Hildebrandt <Ralf.Hildebrandt <at> charite.de>:
> * Andreas Dilger <adilger <at> dilger.ca>:
> 
> > In ext3/4 the top-level inodes are spread around the filesystem, on the
> > assumtion that something like /home or / is allocating trees of
> > unrelated subdirectories at the top level, but that files within those
> > subdirectories ARE related and should be allocated together.
> > 
> > Depending on how many files are in your cache, the 256 * {small files}
> > is likely too big to fit into a single block group (32k inodes, 32k
> > blocks) so you may want to consider marking the first level of
> > subdirectories with the "TOPDIR" flag, that indicates the second-level
> > (256) subdirs should also be spread around the disk.
> 
> How do I mark subdirectories with the "TOPDIR" flag?

Found it: chattr +T
Permalink | Reply | 0 comments |
headers
Ted Ts'o | 6 Dec 2010 22:31
Picon
Picon
Favicon
Gravatar

Re: SQLite and ext3 journalling mode

On Tue, Dec 07, 2010 at 01:42:08AM +0700, Dan Kennedy wrote:
> 
> Are SQLite users that are worried about losing data that has been
> committed (fsynced) better off setting data=journal than
> data=ordered (or even data=writeback)?

Well, they won't be better off a data integrity point of view.
Depending on how SQLite is configured, and how many fsync's are issued
by SQLite in response to application queries, and depending on your
background workload by other applications, using data=journal *might*
be a performance win.

In general, though, if you have background workloads that are
downloading torrents, data=journal is going to hurt a lot.  So I don't
recommend it except for fairly specialized deployments where there's
only one primary user of the file system.

          	 	      	     	  - Ted
Permalink | Reply | 7 comments |

Gmane