Christian Kujau wrote:
> On Mon, 1 Feb 2010 at 17:15, Ralf Hildebrandt wrote:
>
>> What does
>> name_count maxed, losing inode data: dev=00:05, inode=5221
>> mean?
>
> I don't know *what* it means exactly, but this has been reported earlier
> and it's still an open issue:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=445757
> https://bugzilla.redhat.com/show_bug.cgi?id=495207
>
> Christian.
This is all from the audit subsystem; it's not an ext3 issue AFAICT.
I'd push on those bugs if you're concerned.
-Eric
/* AUDIT_NAMES is the number of slots we reserve in the audit_context
* for saving names from getname(). */
#define AUDIT_NAMES 20
static int audit_inc_name_count(struct audit_context *context,
const struct inode *inode)
{
if (context->name_count >= AUDIT_NAMES) {
if (inode)
printk(KERN_DEBUG "name_count maxed, losing inode data: "
"dev=%02x:%02x, inode=%lu
",
MAJOR(inode->i_sb->s_dev),
MINOR(inode->i_sb->s_dev),
inode->i_ino);
On Tue, 2 Feb 2010 at 13:50, Eric Sandeen wrote:
> This is all from the audit subsystem; it's not an ext3 issue AFAICT.
Yeah, after grepping for it I've seen this now. However, I still don't
understand why it's printed at all and if it's something to worry about.
Well, probably not, since it's printed with KERN_DEBUG, but then these
messages should be supressed, no?
Also, can we alter the prinkt somewhat so it says where the message is
coming from? Something like:
Christian Kujau wrote:
> On Tue, 2 Feb 2010 at 13:50, Eric Sandeen wrote:
>> This is all from the audit subsystem; it's not an ext3 issue AFAICT.
>
> Yeah, after grepping for it I've seen this now. However, I still don't
> understand why it's printed at all and if it's something to worry about.
> Well, probably not, since it's printed with KERN_DEBUG, but then these
> messages should be supressed, no?
>
> Also, can we alter the prinkt somewhat so it says where the message is
> coming from? Something like:
Sure, good idea - can you send that patch upstream, cc: eparis@redhat.com ?
because the filesystem in question is indeed ext3. However, this warning
is not generated by ext3 code but by the audit framework. While the
origins of these messages are discussed elsewhere[1] the following
patch modifies the printks in question so that users know where these
messages are coming from. There may be other places within the audit
framework needing the same treatment.