On Aug 19, 2011 8:25 AM, "Eric Shubert" <ejs <at> shubes.net> wrote:
> Interesting stuff regarding running on USB/SSD drives.
>
> -------- Original Message --------
> Subject: Re: Will the SATA drivers in IPCop V2.0 support TRIM?
> Date: Thu, 18 Aug 2011 23:59:36 -0700
> From: David W Studeman <dwstudeman-ceosCSQIA1M@public.gmane.org>
> To: ipcop-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Newsgroups: gmane.comp.security.ipcop.user
> References: <4E4CFE31.4040804 <at> mindspring.com>
> <CAAxQi-895idMdT=XKgKXHhf_mu_PNPHRzdq-s04v9Bauwvvxug <at> mail.gmail.com>
>
> On 8/18/2011 9:22 AM, Bao Ha wrote:
>> On Thu, Aug 18, 2011 at 4:57 AM, ftarz-mn4gwa5WIIQysxA8WJXlww@public.gmane.org
>> <ftarz-mn4gwa5WIIQysxA8WJXlww@public.gmane.org>wrote:
>>
>>> I don't want to start a war of words, but just ask if the SATA drivers
>>> in the IPCop V2.0 kernel will provide TRIM support. I'm thinking of
>>> building a small low power, fanless IPCop box and a small, recycled SSD
>>> would help keep the heat down. Does anyone know if an SSD is a good idea?
>>>
>>> Yes and No.
>>
>> SSD is flash memory and is subject to wear and tear.
>>
>> To use SSD successfully, you would not put the swap and on it. You would
>> also try not to do caching or proxy.
>>
>> You would also need to use these options for the root filesystem in the
>> /etc/fstab:
>>
>> "rw,noatime,commit=60"
>>
>> We calculated that a Kingstom 8GB SSD can survive at least 3 years with a
>> 128KB block write (erase) every 45 seconds. This is for pfSense, but should
>> be applicable to IPCop as well.
>>
>
> Ok, let me try this again with a real email client:
>
> Actually all one needs to do is choose flash install just prior to
> format during install, it is designed to write to disk only once an
> hour, more on that follows. I have always sworn by flash installs (done
> correctly with mkflash) in 1.4 and 2.0 is improved twofold over the
> standard flash method in 1.4. One, you can choose flash install during
> installation, Two, rather than the RD filesystem that really has not
> been necessary since the 2.2 kernel but was the method in 1.4, flash
> installs in 2.0 use TMPFS for the ramdisk which is superior in every
> respect to RD. It needs no formatting and can be resized on the fly
> while mounted with no data loss. I also like the low power draw and low
> heat of a flash installs. It's a winner the whole way around if done
> correctly as is the case with flash installs.
>
>
> The way the flash version works is that /var/log and some of the html
> graphs as well as cron are actually held in a mounted TMPFS (Ramdisk)
> and written to tarballs once an hour for backup ON the disk. These
> tarballs are actually untargzipped on boot as well AFTER the TMPFS is
> mounted as /ram. In the event of a cold reboot or power loss, the most
> logs you will ever lose are close to an hour. I use a UPS and have the
> logs write to my server anyway. Running all the rapidly changing info in
> ram rather than disk and writing to disk only once an hour increases the
> life expectancy of a flash drive to years (15 maybe?) and since you have
> all your graphs and volatile info running in ram rather than on disk, it
> performs extremely well. It also uses NO swap. As far as proxy cache, if
> you want it, give it enough ram for the desired size. I only use the
> proxy for url filtering these days and really need no cache but that's
> my preference.
>
>
> I actually switched flash installs to TMPFS in 2008 on my Raqcop
> adaptation of IPCop for Cobalt hardware. I borrowed it from 2.0svn.
> TMPFS also allows you to use a percentage of ram rather than a fixed
> value. I set mine at 50%. Any of that 50% not used by the info in /ram
> in my case is still available to the system to use if need be. I should
> also mention that I am using flash raid on a Cobalt test box and have
> been able to do so for some time with the 2.0svn branch.On a standard PC
> it's like cake.
>
> --
> Dave Studeman
> http:/www.raqcop.com
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> list mailing list
> list <at> tagcose.com
> https://lists.tagcose.com/mailman/listinfo/list

On Aug 19, 2011 8:25 AM, "Eric Shubert" <ejs <at> shubes.net> wrote:
> Interesting stuff regarding running on USB/SSD drives.
>
> -------- Original Message --------
> Subject: Re: Will the SATA drivers in IPCop V2.0 support TRIM?
> Date: Thu, 18 Aug 2011 23:59:36 -0700
> From: David W Studeman <dwstudeman-ceosCSQIA1M@public.gmane.org>
> To: ipcop-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Newsgroups: gmane.comp.security.ipcop.user
> References: <4E4CFE31.4040804 <at> mindspring.com>
> <CAAxQi-895idMdT=XKgKXHhf_mu_PNPHRzdq-s04v9Bauwvvxug <at> mail.gmail.com>
>
> On 8/18/2011 9:22 AM, Bao Ha wrote:
>> On Thu, Aug 18, 2011 at 4:57 AM, ftarz-mn4gwa5WIIQysxA8WJXlww@public.gmane.org
>> <ftarz-mn4gwa5WIIQysxA8WJXlww@public.gmane.org>wrote:
>>
>>> I don't want to start a war of words, but just ask if the SATA drivers
>>> in the IPCop V2.0 kernel will provide TRIM support. I'm thinking of
>>> building a small low power, fanless IPCop box and a small, recycled SSD
>>> would help keep the heat down. Does anyone know if an SSD is a good idea?
>>>
>>> Yes and No.
>>
>> SSD is flash memory and is subject to wear and tear.
>>
>> To use SSD successfully, you would not put the swap and on it. You would
>> also try not to do caching or proxy.
>>
>> You would also need to use these options for the root filesystem in the
>> /etc/fstab:
>>
>> "rw,noatime,commit=60"
>>
>> We calculated that a Kingstom 8GB SSD can survive at least 3 years with a
>> 128KB block write (erase) every 45 seconds. This is for pfSense, but should
>> be applicable to IPCop as well.
>>
>
> Ok, let me try this again with a real email client:
>
> Actually all one needs to do is choose flash install just prior to
> format during install, it is designed to write to disk only once an
> hour, more on that follows. I have always sworn by flash installs (done
> correctly with mkflash) in 1.4 and 2.0 is improved twofold over the
> standard flash method in 1.4. One, you can choose flash install during
> installation, Two, rather than the RD filesystem that really has not
> been necessary since the 2.2 kernel but was the method in 1.4, flash
> installs in 2.0 use TMPFS for the ramdisk which is superior in every
> respect to RD. It needs no formatting and can be resized on the fly
> while mounted with no data loss. I also like the low power draw and low
> heat of a flash installs. It's a winner the whole way around if done
> correctly as is the case with flash installs.
>
>
> The way the flash version works is that /var/log and some of the html
> graphs as well as cron are actually held in a mounted TMPFS (Ramdisk)
> and written to tarballs once an hour for backup ON the disk. These
> tarballs are actually untargzipped on boot as well AFTER the TMPFS is
> mounted as /ram. In the event of a cold reboot or power loss, the most
> logs you will ever lose are close to an hour. I use a UPS and have the
> logs write to my server anyway. Running all the rapidly changing info in
> ram rather than disk and writing to disk only once an hour increases the
> life expectancy of a flash drive to years (15 maybe?) and since you have
> all your graphs and volatile info running in ram rather than on disk, it
> performs extremely well. It also uses NO swap. As far as proxy cache, if
> you want it, give it enough ram for the desired size. I only use the
> proxy for url filtering these days and really need no cache but that's
> my preference.
>
>
> I actually switched flash installs to TMPFS in 2008 on my Raqcop
> adaptation of IPCop for Cobalt hardware. I borrowed it from 2.0svn.
> TMPFS also allows you to use a percentage of ram rather than a fixed
> value. I set mine at 50%. Any of that 50% not used by the info in /ram
> in my case is still available to the system to use if need be. I should
> also mention that I am using flash raid on a Cobalt test box and have
> been able to do so for some time with the 2.0svn branch.On a standard PC
> it's like cake.
>
> --
> Dave Studeman
> http:/www.raqcop.com
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> list mailing list
> list <at> tagcose.com
> https://lists.tagcose.com/mailman/listinfo/list

On Aug 19, 2011 8:43 AM, "Eric Shubert" <ejs <at> shubes.net> wrote:
> They're both flash storage, so short answer is yes.
> Keep in mind though that each mfr may have different ways of dealing
> with various challenges that flash storage presents, regarding wear and
> performance.
>
> On 08/19/2011 08:35 AM, Dwayne Haught wrote:
>> I was working on this topic this week. Researching and reading about the
>> most ideal way to handle flash storage. Would you think, for the most
>> part, that USB & SSD can be approached in a similar way?
>>
>> On Aug 19, 2011 8:25 AM, "Eric Shubert" <ejs <at> shubes.net
>> <mailto:ejs <at> shubes.net>> wrote:
>> > Interesting stuff regarding running on USB/SSD drives.
>> >
>> > -------- Original Message --------
>> > Subject: Re: Will the SATA drivers in IPCop V2.0 support TRIM?
>> > Date: Thu, 18 Aug 2011 23:59:36 -0700
>> > From: David W Studeman <dwstudeman <at> ovi.com
>> <mailto:dwstudeman <at> ovi.com>>
>> > To: ipcop-user <at> lists.sourceforge.net
>> <mailto:ipcop-user-5NWGOfrQmneRv%2BLV9MX5uipxlwaOVQ5f@public.gmane.org>
>> > Newsgroups: gmane.comp.security.ipcop.user
>> > References: <4E4CFE31.4040804 <at> mindspring.com
>> <mailto:4E4CFE31.4040804 <at> mindspring.com>>
>> > <CAAxQi-895idMdT=XKgKXHhf_mu_PNPHRzdq-s04v9Bauwvvxug <at> mail.gmail.com
>> <mailto:XKgKXHhf_mu_PNPHRzdq-s04v9Bauwvvxug <at> mail.gmail.com>>
>> >
>> > On 8/18/2011 9:22 AM, Bao Ha wrote:
>> >> On Thu, Aug 18, 2011 at 4:57 AM,
>> ftarz <at> mindspring.com
>> <mailto:ftarz <at> mindspring.com>
>> >> <ftarz <at> mindspring.com
>> <mailto:ftarz <at> mindspring.com>>wrote:
>> >>
>> >>> I don't want to start a war of words, but just ask if the SATA drivers
>> >>> in the IPCop V2.0 kernel will provide TRIM support. I'm thinking of
>> >>> building a small low power, fanless IPCop box and a small, recycled SSD
>> >>> would help keep the heat down. Does anyone know if an SSD is a good
>> idea?
>> >>>
>> >>> Yes and No.
>> >>
>> >> SSD is flash memory and is subject to wear and tear.
>> >>
>> >> To use SSD successfully, you would not put the swap and on it. You would
>> >> also try not to do caching or proxy.
>> >>
>> >> You would also need to use these options for the root filesystem in the
>> >> /etc/fstab:
>> >>
>> >> "rw,noatime,commit=60"
>> >>
>> >> We calculated that a Kingstom 8GB SSD can survive at least 3 years
>> with a
>> >> 128KB block write (erase) every 45 seconds. This is for pfSense, but
>> should
>> >> be applicable to IPCop as well.
>> >>
>> >
>> > Ok, let me try this again with a real email client:
>> >
>> > Actually all one needs to do is choose flash install just prior to
>> > format during install, it is designed to write to disk only once an
>> > hour, more on that follows. I have always sworn by flash installs (done
>> > correctly with mkflash) in 1.4 and 2.0 is improved twofold over the
>> > standard flash method in 1.4. One, you can choose flash install during
>> > installation, Two, rather than the RD filesystem that really has not
>> > been necessary since the 2.2 kernel but was the method in 1.4, flash
>> > installs in 2.0 use TMPFS for the ramdisk which is superior in every
>> > respect to RD. It needs no formatting and can be resized on the fly
>> > while mounted with no data loss. I also like the low power draw and low
>> > heat of a flash installs. It's a winner the whole way around if done
>> > correctly as is the case with flash installs.
>> >
>> >
>> > The way the flash version works is that /var/log and some of the html
>> > graphs as well as cron are actually held in a mounted TMPFS (Ramdisk)
>> > and written to tarballs once an hour for backup ON the disk. These
>> > tarballs are actually untargzipped on boot as well AFTER the TMPFS is
>> > mounted as /ram. In the event of a cold reboot or power loss, the most
>> > logs you will ever lose are close to an hour. I use a UPS and have the
>> > logs write to my server anyway. Running all the rapidly changing info in
>> > ram rather than disk and writing to disk only once an hour increases the
>> > life expectancy of a flash drive to years (15 maybe?) and since you have
>> > all your graphs and volatile info running in ram rather than on disk, it
>> > performs extremely well. It also uses NO swap. As far as proxy cache, if
>> > you want it, give it enough ram for the desired size. I only use the
>> > proxy for url filtering these days and really need no cache but that's
>> > my preference.
>> >
>> >
>> > I actually switched flash installs to TMPFS in 2008 on my Raqcop
>> > adaptation of IPCop for Cobalt hardware. I borrowed it from 2.0svn.
>> > TMPFS also allows you to use a percentage of ram rather than a fixed
>> > value. I set mine at 50%. Any of that 50% not used by the info in /ram
>> > in my case is still available to the system to use if need be. I should
>> > also mention that I am using flash raid on a Cobalt test box and have
>> > been able to do so for some time with the 2.0svn branch.On a standard PC
>> > it's like cake.
>> >
>> > --
>> > Dave Studeman
>> > http:/www.raqcop.com <http://www.raqcop.com>
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> > user administration capabilities and model configuration. Take
>> > the hassle out of deploying and managing Subversion and the
>> > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
>> > _______________________________________________
>> > list mailing list
>> > list <at> tagcose.com <mailto:list <at> tagcose.com>
>> > https://lists.tagcose.com/mailman/listinfo/list
>>
>>
>>
>> _______________________________________________
>> list mailing list
>> list <at> tagcose.com
>> https://lists.tagcose.com/mailman/listinfo/list
>
>
> --
> -Eric 'shubes'
>
> _______________________________________________
> list mailing list
> list <at> tagcose.com
> https://lists.tagcose.com/mailman/listinfo/list