System volume root use is 95%, var/ftp is using it all

[JanvdBrink]

Hello,

I have a ReadNas 102 and lately got these error messages that the system volume root use is 95%. After checking the /var folders I noticed that /var/ftp used all the space available. I had FTP enabled for some folders and it looks like the content of those folders is copied into the var/ftp folder.

Maybe a 'stupid' newbe question, but is it normal that this /var/ftp folder is completely used.

Second question: how can I safely remove the content of this /var/ftp folder?

Thanks in advance,

Jan

[Retired_Member · Accepted solution]

Hi.
The ibdata1 always growing is not a ReadyNAS problem, but a MySQL problem, maybe triggered or made worse by LogAnalyzer way to commit queries.
There is plenty of talk online about it. But it seems that there is no easy solution to reducing its size.
One example of thread: http://stackoverflow.com/questions/3456159/how-to-shrink-purge-ibdata1-file-in-mysql
If you don't use it, I suggest removing LogAnalyzer and mysql-server.

[StephenB]

Usually the shares (e.g., btrfs subvolumes) are mounted on /var/ftp, so if the system is working normally you will see the shares (which are not actually in the /var file system).

If you enter "mount" do you see the shares on the list?  Something like

/dev/md127 on /var/ftp/Music type btrfs (rw,noatime,nodiratime,nodatasum,nospace_cache,subvolid=268,subvol=/Music)

If so, deleting files in there will delete the your data (and won't help your problem).

[Retired_Member]

If you want to account what's actually in the OS volume:

# go to root
cd /
# count space usage per folder (only in the same filesystem)
du -d1 -hx .
# go to the biggest folder
cd blablabla
# repeat the operation
du -d1 -hx .
# once you're in the folder that contains the big files
ls -alh

[StephenB]

---

@jak0lantash wrote:

If you want to account what's actually in the OS volume:

# go to root
cd /
# count space usage per folder (only in the same filesystem)
du -d1 -hx .
# go to the biggest folder
cd blablabla
# repeat the operation
du -d1 -hx .
# once you're in the folder that contains the big files
ls -alh

---

du -d1 -hx . works in /var/ftp but the rest won't work unless you unmount the btrfs subvolumes correct?  The cd will just take you into the data volume.

If the space really is in /var/ftp, then it was something written at startup before the data volume.  That has sometimes happened.  Support is of course one option.  

[Retired_Member]

The -x flag is to account for data only in the current filesystem. The data volume being another one, it's not accounted for.

http://linux.die.net/man/1/du

If you really have data into a folder and mounted something on top of it, so I guess you won't be able to account for it this way (because of the cd).

But I'm presuming, the /var/ftp is not the culprit. It was just taken as is by mistake.

The user should do proper accounting with -x flag to make sure.

If you don't want to cd, you can still 

# start with root
du -d1 -hx /
# go to biggest folder
du -d1 -hx /foo
# and so on
# to finish with
ls -alh /foo/bar

[StephenB]

---

@jak0lantash wrote:

The -x flag is to account for data only in the current filesystem. The data volume being another one, it's not accounted for.

http://linux.die.net/man/1/du

On my NAS, using the -x flag in /var/ftp gives me 0 in all folders.  Of course there is nothing in those mount points, and I have no way to put something in there with the NAS running, (and I don't know if I could use it to tell if something were stored in mount points).

[Retired_Member]

I tested it on a Linux machine, once something is mounted on the mount point, you can't account for what was in it (until it's unmounted).

If JanvdBrink does a quick check of the OS volume using du, we'll quickly see if there is no other location with data.

If it's under /var/ftp and there is nothing mounted onto it, then we'll see it.

If it's under /var/ftp and there something mounted onto it, then we won't see it, but it seems unlikely that it was unmounted, and now mounted again.

If it's somewhere else than /var/ftp, then we'll see it 😉

[StephenB]

There was at least one time when an app wrote to the mount point when the data volume wasn't mounted for some reason.  I don't recall exactly how that happened (I think mdgm fixed it).  I agree its not that likely.  It is hard to find of course.

how full is the data volume?

[Retired_Member]

---

@StephenB wrote:

There was at least one time when an app wrote to the mount point when the data volume wasn't mounted for some reason.  I don't recall exactly how that happened (I think mdgm fixed it).  I agree its not that likely.  It is hard to find of course.

---

I seem to remember of a few instances of that happening on OS4, with USB backup job that starts before the USB device is actually mounted, ending up writing the data into the OS volume instead of the USB device.

Let's wait for OP and see what he finds for this case.

[JanvdBrink]

Thank you all for your replies. The ftp was actually leading me on the wrong path. I've been looking into the root file and discovered that  the file idata1 was very large.

root@Goudnas:/var/lib/mysql# ls -lah
total 2.8G
drwx------ 5 mysql mysql 4.0K May 22 19:23 .
drwxr-xr-x 25 root root 4.0K May 20 20:18 ..
-rw-r--r-- 1 root root 0 Mar 23 2014 debian-5.5.flag
-rw-rw---- 1 mysql mysql 2.7G Jun 7 15:35 ibdata1
-rw-rw---- 1 mysql mysql 5.0M Jun 7 15:35 ib_logfile0
-rw-rw---- 1 mysql mysql 5.0M Jun 7 15:35 ib_logfile1
drwx------ 2 mysql root 4.0K Mar 23 2014 mysql
-rw------- 1 root root 6 Mar 23 2014 mysql_upgrade_info
drwx------ 2 mysql mysql 4.0K Mar 23 2014 performance_schema
drwx------ 2 mysql mysql 4.0K Feb 3 21:55 Syslog

Could one of my apps still have a sql process running causing this datafile to grow?

I have the apps:

- AntiVirus Plus

- LogAnalyzer

- istat

Any suggestions on how to solve this are very welcome?

[JanvdBrink]

Hi,

Just saw an old post referring to a similar problem in which it was asked if the poster had installed Loganalyzer. Unfortunately, no response came and the post was closed due to inactivity.

Hopefully some of you guys can suggest what to do. I don't really need LogAnalyzer often, but wonder:

- how this app lead to the sudden growth of the file

- how it is possible to get rid of the large datafile

Thanks

[Retired_Member · Accepted solution]

Hi.
The ibdata1 always growing is not a ReadyNAS problem, but a MySQL problem, maybe triggered or made worse by LogAnalyzer way to commit queries.
There is plenty of talk online about it. But it seems that there is no easy solution to reducing its size.
One example of thread: http://stackoverflow.com/questions/3456159/how-to-shrink-purge-ibdata1-file-in-mysql
If you don't use it, I suggest removing LogAnalyzer and mysql-server.

[JanvdBrink]

Thank you. I actually uninstalled LogAnalyzer and mysql server and removed the specific directories.

Keep my fingers crossed ....