Mount points

  • Hi all,

    Just got my hands on a working APU 1C 4GB. The intended purpose is Firewall / VPN / Squid / SquidGuard possibility Snort as well.

    The idea was to install pfSense full edition after partitioning to a 1MB boundary and setting up TRIM - See Ref 2). However it appears the state tables are written to disk frequently, as well as the obvious logs under /var for the pfSense base system.

    The idea therefore was to mount an external USB HD, during boot for /var and where-ever else frequently accessed data is stored to this external drive.

    This way I can keep the many benefits of the mSATA SSD disk, while not killing it quickly by using a standard disk for the frequently changed data. The aims are to:

    -> Not loose any of the ram to a decompressed image of the system (that I believe the embedded version does?)
    -> Be able to fully utilise the packages of the full edition
    -> Keep the mSATA drive running well as possibly an encrypted backup's storage area


    1. Can anyone give the location of where the "State tables" I guess are stored on the drive?

    2. Apart from /var (ignoring specific additional packages such as squid / snort / etc), is there anywhere else on the drive drive system to beware of frequent writes

    I was planning to use fstat to start analysing this, but am hoping you good people here may be able to give pointers on locations that may require redirection to the spinning disk. As i'm planning on setting it up first before swapping with an embedded Alix system, fstat becomes more challenging to check without live data I guess.

    1. Any useful ideas / points to consider?

    Thanks in advance


    Hopefully these references help anyone who reads unfamiliar:

    Ref 1) Removed

    Ref 2) Useful info located on trim support:

  • Sigh…  Do me a favor and remove that first link.  You've made a decision, probably an incorrect one, based on something I said almost 3 years ago when SSD tech was dramatically different.  All you've done by posting it is to help continue the spread of FUD about SSDs.

    Early MLC SSDs, mostly those with JMicron controllers, had horrible performance and failed constantly.  Newer models do not suffer from these issues and are actually surprisingly difficult to kill (Intel SSDs have, largely, been very reliable since day 1).  Even the lowest-end modern drive is rated for 20GB of writes per day and many go far beyond that.  I've got several Intel and Samsung drives (including an 840 EVO with TLC flash) which have gone 3-4x their rated TBW and are still experiencing no problems.

    What mSATA drive did you get?

  • Hi Jason,

    Sorry link removed. I only posted it as on search I found it, and thought that may be useful.

    After researching it appears Intel seemed to be the best in case of sudden power downs, etc… therefore I went for this drive:

    Intel SSDMCEAC120B301 120Gb SSD ( Intel 525 MLC series SATA6G Solid-State Drive )

    I think the current ALIX system transfers about 40-60GB per week, so I would have to assume this is the proxy data throughput volume (I know that's wrong but a best guess). Then its logs, and whatever else is written frequently to the drive.

    I'll remove the MLC comment for now.  :-[

  • That is a fine drive.  I've got a bunch of the 520/525/530 drives in service in desktops & servers and not a single one has failed on me.

    Your estimate of 40-60GB is a helpful one, though not actually indicative of how many writes are occurring.  Squid, out of the box, doesn't try and cache everything.  I don't recall what the file size limits are for memory & disk caching, but I think they're fairly low.  If you set the RAM cache size to 0 and the max object size for the disk cache to be very large, and assumed a hit rate of 0%, then your writes from squid would be the 40-60GB you mentioned, well under the 20GB/day (for 5 years) the drive is rated for (and it's really underrated).  Practically, it will be a lot less than that.

    As to the logs & RRD data writing to the disk, it's a slow stream of small writes.  It's not enough to worry about though if you're using that drive.

    As far as I'm concerned, you're good to go.  Just run pfSense as it comes out of the box and skip the idea with the external drive.

  • Netgate Administrator

    If you're still worried and have RAM to spare you can choose to move /var and /tmp to ramdrives in System: Advanced: Miscellaneous:
    That's how it's setup in the Nano images specifically to limit writes. It does mean though that you loose all your logs if the box goes down for some reason.


  • I doubt you will be able to kill any SSDs. I have many 30GB-60GB old ssds that have many small VMs running on them 24/7 for years with no special considerations even raid mirrored etc. It takes just a ton to really do in SSDs. All mine pass their manufacturers tests with 90% life left.

  • Thanks Jason that is the confirmation I was looking for  :D

    My experience with ssd's is a myth tv thin client with low io running perfectly for 3 years, win ssd's died every 3 weeks, after 3 months old. Hence I was playing on the cautious side, as my ex server experience was all magnetic based drives, prior to the current job. So sorry but your feedback really helps thanks :)

    I will go with it all on the ssd  :D

    Thanks for the other input in regards to the rams drives Stephen, the Alix box ran out so this is my reasoning not to use ram drives, but it's sound logic. I scripted those to an external hd on the Alix box.

    Thanks also Bryan for confirming further Jason's input, I'm a lot more comfortable with the fact the technology isn't as flaky as searches indicate.

    :D thanks all - a great community here supporting a great package of software.

Log in to reply