Which size NanoBSD embedded would you like to see us ship for 1.2.3?
-
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
http://www.amazon.com/Sandisk-Compact-SDCFH-004G-Package-RescuePRO/dp/B002T84DQI/ref=sr_1_1?ie=UTF8&s=electronics&qid=1263355975&sr=8-1
