Which size NanoBSD embedded would you like to see us ship for 1.2.3?
-
There is some more discussion on NanoBSD in this thread as well:
http://forum.pfsense.org/index.php/topic,16792.0.html4GB cards are reasonably cheap ($15-25) and easy to get ahold of.
Now would also be a good time to ensure that your CF card has good wear leveling.
-
So does this mean my little 512MB card won't be supported anymore?
-
I voted 1GB. For proper industrial flash, I find that 4GB cards are about 3x more expensive than 1GB cards, at around $100 a piece. That's a little too rich for me when the rest of the hardware I'm likely to use has a similar combined cost, this will make my average install about 30% more expensive. The difference between 512MB and 1GB cards is relatively small, but jumping to 2GB almost doubles the 1GB price.
Besides, I see little use for lots of extra storage other than installing a few packages which are probably a few MB each at most. Running a Squid cache or such off CF just doesn't make sense to me.
-
make it as big as you like. i have a 16gb cf card.
but out of choice from there, i would have to go with 4gb. so there is a degree of flexibility of packages to be installed.
memory cards have become really cheap. 1gb and 2gb are not really worth it tbh
-
When you guys say CF card do you specifically mean Compact Flash, or are you referring to any kind of flash memory? I have thought about using the embedded version of pfSense but I dont have a lot of experience with it because having it embedded was never more important than package support for me, so I apologize if this question is ignorant.
-
When you guys say CF card do you specifically mean Compact Flash, or are you referring to any kind of flash memory? I have thought about using the embedded version of pfSense but I dont have a lot of experience with it because having it embedded was never more important than package support for me, so I apologize if this question is ignorant.
The question applies to any embedded install, regardless of what media you install it on. We're mentioning CF because it's almost always the media you use on embedded platforms like ALIX, WRAP, Soekris, repurposed security appliances etc. But it applies to anyone wanting to use the nanoBSD embedded images.
-
Got it, thanks. I just wasn't sure if there was anything specific to CF that was important. After reading your previous post, I am also curious about what you mean by industrial CF. The price tag seems way up there, so I assume it must be very robust, reliable, etc.
-
I voted 1GB. For proper industrial flash, I find that 4GB cards are about 3x more expensive than 1GB cards, at around $100 a piece. That's a little too rich for me when the rest of the hardware I'm likely to use has a similar combined cost, this will make my average install about 30% more expensive. The difference between 512MB and 1GB cards is relatively small, but jumping to 2GB almost doubles the 1GB price.
Besides, I see little use for lots of extra storage other than installing a few packages which are probably a few MB each at most. Running a Squid cache or such off CF just doesn't make sense to me.
Since there won't be enough data on the drive to fill up 4GB or even 2GB (or 1GB…) Someone could probably alter the current embedded image resizing script to make whichever custom-size image you want. Of course the upgrade slices would also need to be resized, but if you're running industrial hardware you probably aren't upgrading them on a whim anyhow. :)
-
We're going to have to put out multiple sized images. 512 MB will be the minimum, and we'll need options for 1, 2, 4, and 8 GB. Embedded can't be one size fits all, especially with package support.
-
Kinda surprised to see 4GB winning so far
-
Still, it would be nice to have a 512MB version.
-
With 1 gig cards being so cheap these days…  Remember nanobsd takes the space and divides it into 2 partitions (3 if you count the config partition).  So you end up with 2 240 meg program areas.  Almost not even enough to accept the upgrade file and leave ample wiggle room.
EDIT: updated the correct space of each partition
-
Would it be possible for some kind of installation mechanism that takes into account the type and capacity of media you are trying to use and partition accordingly?
-
Would it be possible for some kind of installation mechanism that takes into account the type and capacity of media you are trying to use and partition accordingly?
We have considered it but unlikely for the first version. It's a lot of work and adds a lot of room for error on 1.2.3.
-
A smaller image would fit on a larger drive, correct? A previous post makes it sound like 1G is about the minimum usable size, possibly even too small. What's the actual benefit of using a 4G image over a 2G image? For example, one could install the full version on a terabyte hard drive, but it wouldn't really provide any functional benefit over installing it on a 10G drive. What is the point at which it becomes irrelevant?
-
A smaller image would fit on a larger drive, correct? A previous post makes it sound like 1G is about the minimum usable size, possibly even too small. What's the actual benefit of using a 4G image over a 2G image? For example, one could install the full version on a terabyte hard drive, but it wouldn't really provide any functional benefit over installing it on a 10G drive. What is the point at which it becomes irrelevant?
When you start adding packages, the potential for space usage goes up. Way up. Depending on the package you could use several gigs worth of space (e.g. squid cache) but that isn't likely on a CF. Snort takes up a fair amount of space for rules and such, FreeSWITCH uses a lot of space for voicemail, and so on.
If you're just running an unmodified base system with no packages, then yeah, the space usage may be moot. Lots of people add things in on their own, however. Or would at least like the room to run their systems without the filesystem being dangerously close to full all the time.
-
…I think that 2GB would be a reasonable compromise between the need for disk space and the cost of industrial grade flashes, but I agree that the best solution would definitely be having multiple sizes for the images.
-
4GB my indian buddy!
-
In an enterprise situation this specification question should probably not been raised like this. Or is it an interview with the naive customers only? Â :)
I miss a reference to the criteria. There must be some basic statements which fix basic points (just guess):
- "embedded supports installations on boxes with cf/cheapssd disks"
Which criterion implies that embedded is a quasi ro system, and all user data must go to a storage/log server, and who cares how much voicemail weighs.
I miss a reference to the recommended way of installation, which circumstance has implication on this specification question as well. If copying the image by design is done on an other system, then one can take the 1g image and occupy the rest 1 or 3 or 13 gigs with a data or whatever partition for voicemail or other exotic storage uses. And probably nanobsd has facilities to create other partitions itself, then why worry about the image/storage ratio if image < storage. (I would help this myself by writing a partitioning guide, i already wrote one, where i write how to install pfSense to a guid partition: https://secmachine.com/wp/how-tos/pfsense-installation/the-1st-round/ )
And finally I would return to the question about what "embedded" means. Up to now i had an impression that this version of pfSense is made for appliances, it is downgraded functionally and there is no console (kbd+vga) access to it, only serial and network. But since we are talking about gigs of storage under it, it should not be downgraded functionally, it becomes something of general interest.
My understanding would be that embedded means a version of pfSense with restrictions on using the system partition, which usage is quasi ro, that is rare updates of the configuration and very rare upgrades of the system, while all other data is sent to a different storage, most probably nas and logserver. Embedded seems to mean the normal way of using pfSense, using as a router/firewall box only – which means it should not use energy-excessive drives. (While non-embedded, LiveCD version will satisfy the household usage, where there is no nas and log server, and one has to combine the router, the voicemail and the torrent server -- thus uses spinning disks inside the box.)
Sorry if i have missed some points.
- "embedded supports installations on boxes with cf/cheapssd disks"
-
As cmb mentioned, the compromise seems to be to make the build system flexible enough to generate differently sized images… We're using 1GB industrial CF cards aswell for embedded.
