Which size NanoBSD embedded would you like to see us ship for 1.2.3?
-
NanoBSD basically breaks the size into 3 partitions. So if you have a 1GB card you would end up with 2 - 450 megabyte partitions + the configuration storage area.
We plan on support packages in NanoBSD so choose your size well!
Oh, you cannot even find anything smaller than 4GB at most stores such as wal-mart, best-buy, etc now.
-
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.
-
Is there an issue with some hardware (32 bit) being unable to boot from >2GB CF cards? ???
-
And again, i guess there may be problems with this decisionmaking situation. I suggested that the original problem is the question (see my post above), then there may be a problem with interpreting the likely 2/3 votes for 4g, and i would wonder if the factory will spend time and energy with shipping nano in several size versions.
Do those who vote for 4g mean that they want the system partition be that size, or they just are to use this size of cf? If the factory image always lays down a 1g system partition wouldn't it be enough to fit the vast majority of the installations including the packages? Wouldn't it be an option to ship a simple script which adds another partition to make the other 1,3,7 or 15 gigs available, and adds it to the fstab, so everyone can enjoy their actual sizes?
-
I have several systems deployed where 256MB CF cards are used, does this pool means that in the future I won't be able to upgrade them to newer releases?
-
I have several systems deployed where 256MB CF cards are used, does this pool means that in the future I won't be able to upgrade them to newer releases?
Yes, 512 MB will be the minimum for 1.2.3 and newer. The dual partition scheme of nanobsd means double the space is required, and we're at a 256 MB minimum each to ensure future upgradability (actually less than that, part is the configuration partition).
-
Yes, 512 MB will be the minimum for 1.2.3 and newer. The dual partition scheme of nanobsd means double the space is required, and we're at a 256 MB minimum each to ensure future upgradability (actually less than that, part is the configuration partition).
so a 4gb image will fit on a 4gb card and not need an 8gb card?
can a 2gb image accept a 4gb image upgrade or is it a complete reinstall?
silly me…... has put a 2gb image on a 4gb card!!!
-
Yes, you can flash a smaller image to a larger card.
No, you can not switch from one size to another from my knowledge.No problem.
As a side note to the wear leveling. Almost all newer cards use wear leveling now. If you buy a cheap 8Go card and flash the 2GB image there will effectively be 6Go not used.
However, the wear leveling of flash cards will use these cells for wear leveling. This means that the life expectancy of your cheap Compact Flash card will now be effectively 4 times as long.I am still using the same consumer 1GB apacer 133x card I purchased over 2 years ago with my Full install. Although the card is only 1Go I am only using ~120Mo of space, this means that the card life should be expected to be a lot longer, based on the number of write cycles per cell, which doesn't change.
Something to keep in mind.
Side Note: The (very cheap) no name 1Go CF cards I got from PCengines.ch with my alix boards failed within the year, it appears these cards did not have wear leveling. This was even with a embedded release on them. You should be safe to assume that any consumer Compact flash card with a higher operating speed should have wear leveling. Atleast from the major brands.
e.g. Kingston, Sandisk and Apacer. Others might work as well.
-
that's interesting…..
are you sayng that it's actually better to have unused space on a CF card?
so with my example above, where i'm using a 2gb image on a 4gb card..... the card would have a longer lifecycle that with a 4gb image on a 4gb CF? card for card of course!
-
Well this is a bit late but…I assume this card would work OK
