I have my hard drive partitioned such that my /usr/local and /home directories are on separate partitions from the root. They are both quite large, and have plenty of free space.

The other day I began to compile libreoffice from source, which three days later was finally complete. The compile process seems to have completed successfully, but while it was doing so it mysteriously took up nearly a Gig of hard drive space on my root partition.

The directory I was using to compile libreoffice is located on the /home partition. I have been scouring my /root parition for any files that were created during the time the libreoffice was compiling (during which the computer was not being used for any other purpose) and I cannot find anything that would account for this disappearing free space. There are no individual files that are anywhere near that size, and there are no groups of smaller files that I can find that would add up to that.

What could the libreoffice have placed on my hard drive that would take up nearly a Gig of space, but not leave any trace of its having been created on the date that it appeared, and which is not located in any /tmp directory? And particularly when the compiling itself was being done a completely different partition?

Any help would be greatly appreciated. This mystery free space eater has left it so my computer barely functions because the /root is now completely full.

Thanks in advance!

Id check the logs
Or, at least force a logrotate...basically flushing the system...
But, I use Manjaro, never had that one before...
Three whole days? Weird. It took less than four hours to compile a kernel on a Compaq D51s...three days, LOL, that is some hypercompilin'
Thor

Which logs should I look in?

I tried logrotate -f /etc/logrotate.conf, and it recoverd about 2MB of what had been 900MB of available space.

And it didn't actually take three days to compile. It was only two days. And this is a Dell Optiplex GX260.

Ow...good
Logrotate does clean things up...hmm, can you map out the disk? That should give you a more visual cue to the disk usage...
Try to focus on places like /tmp, /var/log and such...
DO NOT (but, you know this) delete stuff! Check here first...in case of doubt...
Thor

Well, I did a ls -hlRS starting from / and dumped it into a file. There does not appear to be anything that was created or modified during the time the compile was running that would account for that much data space being consumed.

The only thing I can think of is that whatever files are taking up that space do not have create/modification dates within the time frame of when the compile was being done, because doing a grep 'Sep 14' returns only those files in the compile directory on /home. (Or other files that are regularly updated and not of abnormal size.)

And it would have to be a series of smaller files because doing a grep 'M' returns mostly directories, or files that I already know were there before. Doing a grep 'G' returns a couple of directories which are on /usr/local or /home.

OW! Could (someone/ANYone correct me if I'm wrong) it be that there was a download of missing stuff during compile? How did you compile? As Root? As the normal user (you)?
Is your disk in ONE lump (a Xubuntu I installed for someone is)?
Just...a flash that came to me...
Thor

Are you certain that all your partitions were mounted when you did the compile? If, for example, /usr/local were not mounted, then files would have been stored under the /usr/local directory in the root filesystem. and those files would be hidden while the separate /usr/local partition was mounted. There is a way to access files buried under an active mount point, but for something like /usr/local it's probably easiest just to umount it and take a look.

You can use "ls -lc" or find with the "-ctime" test to look for files with a recent status change. That will catch files that got installed with their original modification times preserved, but I doubt that's what happened here.

It did download a whole bunch of stuff, but it did that at the very beginning of the compile process, and it put all of that stuff in a subdirectory of the compile directory on /home.

I compiled it using configure and make. I was logged in as root, but I've already checked root's home directory and there is nothing there either.

I don't know exactly what you mean by "ONE lump," but I doubt it because I installed my OS using a very basic install and then manually compiled a lot of stuff to install afterwards. There is more data on my /usr/local than on my root partition. I even moved a bunch of libs from /usr/lib to /usr/local/lib to make sure I can keep space free on the root partition.

Yes, I'm sure they were all mounted properly because, while the compile was running on one terminal, I would occasionally switch to another terminal and do a df -h to monitor the free space on each of the partitions.

From this I know that whatever it was happened near the end of the 48-hour compile process. Everything was fine until the morning of the day that it finally finished. When I got up that morning and saw that the compiling was still going on and checked the df, I saw that what had been more than 600MB of free space when I went to bed the previous night had become 0.

The compile had actually used up about 300MB of free space on root by the time I went to bed that evening, but it was that final night that took away all the rest. And yet, when I do the grep 'Sep 14' against my ls file of the complete contents of my hard drive, nothing comes up that is anywhere near that large.

Does "du -xhs /" give a result that is consistent with the used space reported by "df -h /" ?

1 members found this post helpful.

That did it. I never knew about "du," but using that I was able to determine that it was the .ccache/ directory under /root/ that was the problem. Since ccache stores information about compiles, it makes sense that that data would be generated when a huge compliation is taking place. And since I was logged in as root during the compile, it makes sense that it would show up in root's home directory.

I just don't know why I never caught that on the ls output...

Anyway, thank you for the help!

Only if you used the "-a" option of ls to show ALL files.

I realized that after I thought about it a little bit. My initial query should have been done like

Thanks again!