Full /dev/mdx mounts...

Status
Not open for further replies.

DrKK

FreeNAS Generalissimo
Joined
Oct 15, 2013
Messages
3,630
So, I was thinking about this discussion, wherein the fact that FreeNAS used relatively small "RAMDisk"-like mounts to do certain things (such as hold certain logs) turned into being a small problem because he had some kind of SMB/network issue which caused his /var/log/samba files to grow to huge sizes, thus blowing away the memory device mount, and seizing up his NAS.

First of all: I notice mine were pretty big too. Same files as described by him. Tens of megabytes--filled about half that mount. So I shut down the CIFS service daemons, and cleaned out those logs, and restarted. No harm done.

But I definitely notice that one of my OTHER memory-device mounts, which is capitated to the /etc directory, is pretty much totally full. Like, 96% or something. I don't think(?) there are logs in there or anything else that is going to grow and cause a problem, hence there's no harm in having it so close to the wire...but....am I right about that? I'm not a FreeBSD sensei, so hopefully someone will confirm that.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Yeah, that is always very full. It always has been. It's so small because there's so little free space available on the 2GB image. Mine's 91% full. If you check out bugs.freenas.org we've had problems with that being too small for some users. Usually its people with 100s or 1000s of datasets because all those graphs in the Reporting tab are stored there. So people with lots of zpools/datasets end up with a huge amount of information in very short order.

If you do your homework you'll find plenty of people have complained about issues related to /var, /data, and /tmp. /var can be resolved by using the syslog dataset. As for /data that's a problem for VERY large systems and /tmp shouldn't ever have a problem since you shouldn't be storing stuff on it as a regular course of business.

Hope this helps!
 

Dusan

Guru
Joined
Jan 29, 2013
Messages
1,165
I think you are mixing apples & oranges here.
Yeah, that is always very full. It always has been. It's so small because there's so little free space available on the 2GB image. Mine's 91% full.
DrKK's question is about the ramdisks. You speak about the USB stick size. The ramdisks size has absolutely no relation to the USB stick size. The ramdisks are initialized on boot and you can easily increase their capacity (edit few numbers in the config files). However, making them too big just wastes memory (and would increase the FreeNAS memory requirements).
If you check out bugs.freenas.org we've had problems with that being too small for some users. Usually its people with 100s or 1000s of datasets because all those graphs in the Reporting tab are stored there. So people with lots of zpools/datasets end up with a huge amount of information in very short order.
Yes, /var is a ramdisk and in some cases can fill quickly with logs. However, its size is not related to the USB stick. The current size is an iXsystems design decision that balances the size of the /var filesystem vs. the memory requirements of FN.
As for /data that's a problem for VERY large systems and /tmp shouldn't ever have a problem since you shouldn't be storing stuff on it as a regular course of business.
Again, /data is not a ramdisk, it is a USB stick partition. /tmp is a ramdisk and it is actually the same device as /var.

So, to sum the various FreeNAS filesystems:

USB stick partitions (if you want to increase those you need a bigger USB stick and you need to build your own bigger FN image):
  • the root filesystem: it's the first or second USB partition (they alternate when you upgrade), ~1GB, 70% full, mounted read-only, mostly contains the FreeNAS binaries
  • /data: the fourth USB stick partition, ~20MB, normally almost empty, read-write, contains all the changeable FreeNAS bits that need to survive reboots: the config DB, geli keys, zfs pool configuration cache, SSH certificates for replication (trivia: but not the root's public SSH key -- that one is stored on the root partition and the GUI mounts it briefly R/W when you change the key), the backup of the reporting graphs data and the crash dumps. This one may get full if you have tons of reporting graphs, however /var usually fills sooner.
  • the third partition is, if I remember correctly, only used during upgrades
The ramdisks: (created on boot, you can change their sizes by editing the md_size files on the USB stick -- the size is in 512 byte blocks):
  • /dev/md0, mounted as /etc: 5MB, ~90% full, contains the config files for the system, initialized on boot from /conf/base/etc (size is in /conf/base/etc/md_size), additional configs are created/modified by FreeNAS based on the config DB and changes you do in GUI. There is very little risk that this one will be filled (unless you start hacking things). That's why the available space is so tight -- the size of the config files doesn't change much. You would probably have to add thousands of CIFS shares to make smb.conf outgrow the ramdisk :).
  • /dev/md1, mounted as /mnt: 1MB :), almost empty, it is there so that the system can dynamically create mountpoints when you import volumes. Again, almost impossible to fill in normal conditions.
  • /dev/md2, mounted as /var (but also contains /tmp as it is a symlink to /var/tmp): 160MB (you can change the size by editing /conf/base/var/md_size), starts almost empty, contains all the changing stuff that doesn't survive reboots -- logs, reporting data (but those are also backed up every hour to /data), temporary files, ... You can move part of it (the logs -- /var/log) to the syslog dataset (so, for example the reporting graphs data will not be moved).
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
I was just trying to compare his 96% full to my 91% full.

Good writeup Dusan!
 
Status
Not open for further replies.
Top