Bug 6441

Created attachment 2454 [details]
tune2fs during problem

Created attachment 2455 [details]
tune2fs after reboot

The problem happened again.
I performed a tune2fs -l /dev/sda5 during the problem and after a reboot.
Here is the diff:

diff log_tune2fs_problem.txt log_tune2fs_reboot.txt 
16,17c16,17
< Free blocks:              9439983
< Free inodes:              3624885
---
> Free blocks:              4779944
> Free inodes:              3624044
28,30c28,30
< Last mount time:          Wed Jun 13 19:19:56 2012
< Last write time:          Wed Jun 13 19:19:56 2012
< Mount count:              12
---
> Last mount time:          Thu Jun 14 08:01:08 2012
> Last write time:          Thu Jun 14 08:01:08 2012
> Mount count:              13
34c34
< Lifetime writes:          149 GB
---
> Lifetime writes:          168 GB
41a42
> First orphan inode:       1443840

If a file is deleted, while a program has it open, the space is not released
until the program closes the file, which of course happens during a reboot.

What types of files were being deleted?

CC: (none) => davidwhodgins

The problem is that there is no such file.
I performed a 'du --max-depth=1 -h /home' to see if a directory was growing very large. But no such directory.
Something is written, but I don't know where.
The only tasks I was performing where: compilation compilation compilation.

YC

Some programs create files, open them, and then immediately unlink the file,
effectively creating a "no name" temp file.

A file such as that, will not show up in any tool looking at the filesystem,
but the space will not be released until the program that created the file
closes.

There is no way to find which program is writing this file ?

That's why I was curious about what type of files were deleted.

lsof -n|grep deleted

run as root, should show you which programs have deleted files
still open.

OK, thanks for your tool.
I finally managed to found the problem.
The problem doesn't come from a deleted file.
It comes from .xsession-errors.
This file (seems not to be reported by 'du') keeps on growing.

wc -l .xsession-errors 
95268391 .xsession-errors


ls -l .xsession-errors 
-rw------- 1 collette collette 4830811560 juin  16 10:53 .xsession-errors

ls -l .xsession-errors 
-rw------- 1 collette collette 4831500031 juin  16 10:53 .xsession-errors

ls -l .xsession-errors 
-rw------- 1 collette collette 6464511422 juin  16 11:47 .xsession-errors


The content of .xsession-errors:

tail .xsession-errors 
[/usr/bin/nepomukservicestub] "10:51:08 Reference to page with free remap dp = 15333, remap = 15333
"
[/usr/bin/nepomukservicestub] "10:51:08 Reference to page with free remap dp = 15333, remap = 15333
"
[/usr/bin/nepomukservicestub] "10:51:08 Reference to page with free remap dp = 15333, remap = 15333
"
[/usr/bin/nepomukservicestub] "10:51:08 Reference to page with free remap dp = 15333, remap = 15333
"
[/usr/bin/nepomukservicestub] "10:51:08 Reference to page with free remap dp = 15333, remap = 15333
"

So, the responsible of my problem: nepomuk.
How do I continue:
- Do I close this bug and reopen another one ?
- Do I rename the bug report ?

Thanks for your support.

YC

Probably best to close this bug report, and open a new one about nepomuk
writing excessive number of messages to the .xsession-errors file.

Ignore comment 10.  I just realized Olav has modified the description.

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD