Thread: which Xeon processors don't have the context switching problem
I recall a reference on the list indicating that newer Xeon processors don't suffer from the context switching problem reported last year. In searching the archives, I can't find any specific info indentifying which Xeon processors don't have this problem. Anyone point me to a reference? Is this in any way related to the version of Postgresql one is running? We're headed for 8, but have a bit of work before we can get there. We are currently on 7.4.16. Thanks for any info. -- Until later, Geoffrey Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
> I recall a reference on the list indicating that newer Xeon processors > don't suffer from the context switching problem reported last year. > > In searching the archives, I can't find any specific info indentifying > which Xeon processors don't have this problem. > > Anyone point me to a reference? We recently migrated to a woodcrest @ 3 GHz from a 2 Ghz opteron. The woodcrest seems to be enjoying doing db-related work. I don't have numbers other than load is much lower now. > Is this in any way related to the version of Postgresql one is running? > We're headed for 8, but have a bit of work before we can get there. > We are currently on 7.4.16. We are at 7.4.14 which works fine atm. regards Claus
Re: which Xeon processors don't have the context switching problem
From
"Steinar H. Gunderson"
Date:
On Fri, Feb 23, 2007 at 02:05:57PM -0500, Geoffrey wrote: > In searching the archives, I can't find any specific info indentifying > which Xeon processors don't have this problem. AFAIK the cut-off point is at the Woodcrests. They are overall much better suited to PostgreSQL than the older Xeons were. It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon names even though they're making significant architecture changes, but that's life, I guess. /* Steinar */ -- Homepage: http://www.sesse.net/
Steinar H. Gunderson wrote: > On Fri, Feb 23, 2007 at 02:05:57PM -0500, Geoffrey wrote: > > In searching the archives, I can't find any specific info indentifying > > which Xeon processors don't have this problem. > > AFAIK the cut-off point is at the Woodcrests. They are overall much better > suited to PostgreSQL than the older Xeons were. > > It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon > names even though they're making significant architecture changes, but that's > life, I guess. AFAIR Intel has been calling their server processors Xeon since Pentium Pro's, at least. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Re: which Xeon processors don't have the context switching problem
From
"Steinar H. Gunderson"
Date:
On Fri, Feb 23, 2007 at 04:53:18PM -0300, Alvaro Herrera wrote: >> It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon >> names even though they're making significant architecture changes, but that's >> life, I guess. > AFAIR Intel has been calling their server processors Xeon since Pentium > Pro's, at least. Yes, that was sort of my point. :-) /* Steinar */ -- Homepage: http://www.sesse.net/
Geoffrey, > I recall a reference on the list indicating that newer Xeon processors > don't suffer from the context switching problem reported last year. Just to be clear, it's a software problem which affects all architectures, including AMD and Sparc. It's just *worse* on the PIII and P4 generation Xeons. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
Josh Berkus wrote: > Geoffrey, > >> I recall a reference on the list indicating that newer Xeon processors >> don't suffer from the context switching problem reported last year. > > Just to be clear, it's a software problem which affects all architectures, > including AMD and Sparc. It's just *worse* on the PIII and P4 generation > Xeons. Thanks, that's what I need to hear. They've since cut a deal for Operton based hardware, so the point is now moot. -- Until later, Geoffrey Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
Josh Berkus wrote:
> Geoffrey,
>
>> I recall a reference on the list indicating that newer Xeon processors
>> don't suffer from the context switching problem reported last year.
>
> Just to be clear, it's a software problem which affects all architectures,
> including AMD and Sparc. It's just *worse* on the PIII and P4 generation
> Xeons.
>
Also isn't it pretty much *not* a problem with current versions of
PostgreSQL?
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Joshua D. Drake wrote: > Josh Berkus wrote: >> Geoffrey, >> >>> I recall a reference on the list indicating that newer Xeon processors >>> don't suffer from the context switching problem reported last year. >> Just to be clear, it's a software problem which affects all architectures, >> including AMD and Sparc. It's just *worse* on the PIII and P4 generation >> Xeons. >> > > Also isn't it pretty much *not* a problem with current versions of > PostgreSQL? As I've heard. We're headed for 8 as soon as possible, but until we get our code ready, we're on 7.4.16. -- Until later, Geoffrey Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
On 2/23/07, Joshua D. Drake <jd@commandprompt.com> wrote: > Also isn't it pretty much *not* a problem with current versions of > PostgreSQL? We had a really *big* scalability problem with a quad Xeon MP 2.2 and PostgreSQL 7.4. The problem is mostly gone since we upgraded to 8.1 a year ago. Woodcrest seems to perform really well with PostgreSQL according to what I can read on the Internet so we will probably change the server for a dual Woodcrest in a few months. -- Guillaume
On 2/23/07, Geoffrey <esoteric@3times25.net> wrote: > As I've heard. We're headed for 8 as soon as possible, but until we get > our code ready, we're on 7.4.16. You should move to at least 8.1 and possibly 8.2. It's not a good idea to upgrade only to 8 IMHO. -- Guillaume
Alvaro Herrera wrote: > Steinar H. Gunderson wrote: >> On Fri, Feb 23, 2007 at 02:05:57PM -0500, Geoffrey wrote: >>> In searching the archives, I can't find any specific info indentifying >>> which Xeon processors don't have this problem. >> AFAIK the cut-off point is at the Woodcrests. They are overall much better >> suited to PostgreSQL than the older Xeons were. >> >> It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon >> names even though they're making significant architecture changes, but that's >> life, I guess. > > AFAIR Intel has been calling their server processors Xeon since Pentium > Pro's, at least. > Almost. Xeon was the new name for the "Pro" series. Instead of Pentium II Pro, we got Pentium II Xeon. The whole Pentium Pro line was a server line, which is why initial Pentium-II CPUs were significantly slower for server apps than the much older ppro (which still runs pg at a reasonable speed if you have enough of them and a low budget, btw) //Magnus
Guillaume Smet wrote: > On 2/23/07, Geoffrey <esoteric@3times25.net> wrote: >> As I've heard. We're headed for 8 as soon as possible, but until we get >> our code ready, we're on 7.4.16. > > You should move to at least 8.1 and possibly 8.2. It's not a good idea > to upgrade only to 8 IMHO. When I said 8, I meant whatever the latest greatest 8 is. Right now, that looks like 8.2.3. -- Until later, Geoffrey Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin
Geoffrey wrote:
> Guillaume Smet wrote:
>> On 2/23/07, Geoffrey <esoteric@3times25.net> wrote:
>>> As I've heard. We're headed for 8 as soon as possible, but until we get
>>> our code ready, we're on 7.4.16.
>>
>> You should move to at least 8.1 and possibly 8.2. It's not a good idea
>> to upgrade only to 8 IMHO.
>
> When I said 8, I meant whatever the latest greatest 8 is. Right now,
> that looks like 8.2.3.
No. The latest version of 8.2 is 8.2.3, there is also 8.1 which is at
8.1.8 and 8.0 which is at 8.0.12.
They are all different *major* releases.
IMO, nobody should be running anything less than 8.1.8.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Say that I have a dual-core processor (AMD64), with, say, 2GB of memory
to run PostgreSQL 8.2.3 on Fedora Core X.
I have the option to put two hard disks (SATA2, most likely); I'm
wondering
what would be the optimal configuration from the point of view of
performance.
I do have the option to configure it in RAID-0, but I'm sort of
reluctant; I think
there's the possibility that having two filesystems that can be accessed
truly
simultaneously can be more beneficial. The question is: does PostgreSQL
have separate, independent areas that require storage such that performance
would be noticeably boosted if the multiple storage operations could be
done
simultaneously?
Notice that even with RAID-0, the "twice the performance" may turn into
an illusion --- if the system requires access from "distant" areas of
the disk
("distant" as in many tracks apart), then the back-and-forth travelling of
the heads would take precedence over the doubled access speed ... Though
maybe it depends on whether accesses are in small chunks (in which case
the cache of the hard disks could take precedence).
Coming back to the option of two independent disks --- the thing is: if it
turns out that two independent disks are a better option, how should I
configure the system and the mount points? And how would I configure
PostgreSQL to take advantage of that?
Advice, anyone?
Thanks,
Carlos
--
Carlos Moreno <moreno_pg@mochima.com> writes:
> The question is: does PostgreSQL have separate, independent areas that
> require storage such that performance would be noticeably boosted if
> the multiple storage operations could be done simultaneously?
The standard advice in this area is to put pg_xlog on a separate
spindle; although that probably is only important for update-intensive
applications. You did not tell us anything about your application...
regards, tom lane
On Feb 25, 2007, at 04:39 , Carlos Moreno wrote: > I do have the option to configure it in RAID-0, but I'm sort of > reluctant; I think > there's the possibility that having two filesystems that can be > accessed truly > simultaneously can be more beneficial. The question is: does > PostgreSQL > have separate, independent areas that require storage such that > performance > would be noticeably boosted if the multiple storage operations > could be done > simultaneously? Putting the WAL (aka pg_xlog) on a separate disk will take some load off your main database disk. See http://www.varlena.com/GeneralBits/ Tidbits/perf.html for this. It is also possible to put individual tables and/or indexes on separate disks by using tablespaces: "For example, an index which is very heavily used can be placed on a very fast, highly available disk, such as an expensive solid state device. At the same time a table storing archived data which is rarely used or not performance critical could be stored on a less expensive, slower disk system." (http://www.postgresql.org/docs/8.2/interactive/manage-ag- tablespaces.html) In both cases, the performance benefits tend to be relative to the amount of write activity you experience, and the latter solution assumes you know where the hotspots are. If you have two tables that see continuous, intense write activity, for example, putting each on a separate disk Alexander.
A related question: Is it sufficient to disable write cache only on the disk where pg_xlog is located? Or should write cache be disabled on both disks? Thanks Peter On 2/25/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Carlos Moreno <moreno_pg@mochima.com> writes: > > The question is: does PostgreSQL have separate, independent areas that > > require storage such that performance would be noticeably boosted if > > the multiple storage operations could be done simultaneously? > > The standard advice in this area is to put pg_xlog on a separate > spindle; although that probably is only important for update-intensive > applications. You did not tell us anything about your application... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate >
On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote:
> A related question:
> Is it sufficient to disable write cache only on the disk where pg_xlog
> is located? Or should write cache be disabled on both disks?
>
When PostgreSQL does a checkpoint, it thinks the data pages before the
checkpoint have successfully made it to disk.
If the write cache holds those data pages, and then loses them, there's
no way for PostgreSQL to recover. So use a battery backed cache or turn
off the write cache.
Regards,
Jeff Davis
On 2/26/07, Jeff Davis <pgsql@j-davis.com> wrote: > On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote: > > A related question: > > Is it sufficient to disable write cache only on the disk where pg_xlog > > is located? Or should write cache be disabled on both disks? > > > > When PostgreSQL does a checkpoint, it thinks the data pages before the > checkpoint have successfully made it to disk. > > If the write cache holds those data pages, and then loses them, there's > no way for PostgreSQL to recover. So use a battery backed cache or turn > off the write cache. Sorry for for not being familar with storage techonologies... Does "battery" here mean battery in the common sense of the word - some kind of independent power supply? Shouldn't the disk itself be backed by a battery? As should the entire storage subsystem? Thanks Peter > > Regards, > Jeff Davis > >
On Tue, 2007-02-27 at 01:11 +0100, Peter Kovacs wrote:
> On 2/26/07, Jeff Davis <pgsql@j-davis.com> wrote:
> > On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote:
> > > A related question:
> > > Is it sufficient to disable write cache only on the disk where pg_xlog
> > > is located? Or should write cache be disabled on both disks?
> > >
> >
> > When PostgreSQL does a checkpoint, it thinks the data pages before the
> > checkpoint have successfully made it to disk.
> >
> > If the write cache holds those data pages, and then loses them, there's
> > no way for PostgreSQL to recover. So use a battery backed cache or turn
> > off the write cache.
>
> Sorry for for not being familar with storage techonologies... Does
> "battery" here mean battery in the common sense of the word - some
> kind of independent power supply? Shouldn't the disk itself be backed
> by a battery? As should the entire storage subsystem?
>
Yes, a battery that can hold power to keep data alive in the write cache
in case of power failure, etc., for a long enough time to recover and
commit the data to disk.
So, a write cache is OK (even for pg_xlog) if it is durable (i.e. on
permanent storage or backed by enough power to make sure it gets there).
However, if PostgreSQL has no way to know whether a write is durable or
not, it can't guarantee the data is safe.
The reason this becomes an issue is that many consumer-grade disks have
write cache enabled by default and no way to make sure the cached data
actually gets written. So, essentially, these disks "lie" and say they
wrote the data, when in reality, it's in volatile memory. It's
recommended that you disable write cache on such a device.
Regards,
Jeff Davis
Jeff Davis wrote: >> Sorry for for not being familar with storage techonologies... Does >> "battery" here mean battery in the common sense of the word - some >> kind of independent power supply? Shouldn't the disk itself be backed >> by a battery? As should the entire storage subsystem? >> > > Yes, a battery that can hold power to keep data alive in the write cache > in case of power failure, etc., for a long enough time to recover and > commit the data to disk. Just to expand a bit - the battery backup options are available on some raid cards - that is where you would be looking for it. I don't know of any hard drives that have it built in. Of cause another reason to have a UPS for the server - keep it running long enough after the clients have gone down so that it can ensure everything is on disk and shuts down properly. > So, a write cache is OK (even for pg_xlog) if it is durable (i.e. on > permanent storage or backed by enough power to make sure it gets there). > However, if PostgreSQL has no way to know whether a write is durable or > not, it can't guarantee the data is safe. > > The reason this becomes an issue is that many consumer-grade disks have > write cache enabled by default and no way to make sure the cached data > actually gets written. So, essentially, these disks "lie" and say they > wrote the data, when in reality, it's in volatile memory. It's > recommended that you disable write cache on such a device. From all that I have heard this is another advantage of SCSI disks - they honor these settings as you would expect - many IDE/SATA disks often say "sure I'll disable the cache" but continue to use it or don't retain the setting after restart. -- Shane Ambler pgSQL@Sheeky.Biz Get Sheeky @ http://Sheeky.Biz
On 2/27/07, Shane Ambler <pgsql@sheeky.biz> wrote: > Jeff Davis wrote: > > >> Sorry for for not being familar with storage techonologies... Does > >> "battery" here mean battery in the common sense of the word - some > >> kind of independent power supply? Shouldn't the disk itself be backed > >> by a battery? As should the entire storage subsystem? > >> > > > > Yes, a battery that can hold power to keep data alive in the write cache > > in case of power failure, etc., for a long enough time to recover and > > commit the data to disk. > > Just to expand a bit - the battery backup options are available on some > raid cards - that is where you would be looking for it. I don't know of > any hard drives that have it built in. > > Of cause another reason to have a UPS for the server - keep it running > long enough after the clients have gone down so that it can ensure > everything is on disk and shuts down properly. > > > So, a write cache is OK (even for pg_xlog) if it is durable (i.e. on > > permanent storage or backed by enough power to make sure it gets there). > > However, if PostgreSQL has no way to know whether a write is durable or > > not, it can't guarantee the data is safe. > > > > The reason this becomes an issue is that many consumer-grade disks have > > write cache enabled by default and no way to make sure the cached data > > actually gets written. So, essentially, these disks "lie" and say they > > wrote the data, when in reality, it's in volatile memory. It's > > recommended that you disable write cache on such a device. > > From all that I have heard this is another advantage of SCSI disks - > they honor these settings as you would expect - many IDE/SATA disks > often say "sure I'll disable the cache" but continue to use it or don't > retain the setting after restart. As far as I know, SCSI drives also have "write cache" which is turned off by default, but can be turned on (e.g. with the sdparm utility on Linux). The reason I am so much interested in how write cache is typically used (on or off) is that I recently ran our benchmarks on a machine with SCSI disks and those benchmarks with high commit ratio suffered significantly compared to our previous results "traditionally" obtained on machines with IDE drives. I wonder if running a machine on a UPS + 1 hot standby internal PS is equivalent, in terms of data integrity, to using battery backed write cache. Instinctively, I'd think that UPS + 1 hot standby internal PS is better, since this setup also provides for the disk to actually write out the content of the cache -- as you pointed out. Thanks Peter > > > -- > > Shane Ambler > pgSQL@Sheeky.Biz > > Get Sheeky @ http://Sheeky.Biz >
Just remember that batteries (in both RAID cards and UPSes) wear out and will eventually have to be replaced. It depends how critical your data is, but if you only have a UPS, you risk badness in the off chance that your power fails and you haven't replaced your UPS battery.
On Feb 27, 2007, at 12:27 AM, Peter Kovacs wrote:
I wonder if running a machine on a UPS + 1 hot standby internal PS is
equivalent, in terms of data integrity, to using battery backed write
cache. Instinctively, I'd think that UPS + 1 hot standby internal PS
is better, since this setup also provides for the disk to actually
write out the content of the cache -- as you pointed out.
Peter Kovacs wrote: >> > The reason this becomes an issue is that many consumer-grade disks have >> > write cache enabled by default and no way to make sure the cached data >> > actually gets written. So, essentially, these disks "lie" and say they >> > wrote the data, when in reality, it's in volatile memory. It's >> > recommended that you disable write cache on such a device. >> >> From all that I have heard this is another advantage of SCSI disks - >> they honor these settings as you would expect - many IDE/SATA disks >> often say "sure I'll disable the cache" but continue to use it or don't >> retain the setting after restart. > > As far as I know, SCSI drives also have "write cache" which is turned > off by default, but can be turned on (e.g. with the sdparm utility on > Linux). The reason I am so much interested in how write cache is > typically used (on or off) is that I recently ran our benchmarks on a > machine with SCSI disks and those benchmarks with high commit ratio > suffered significantly compared to our previous results > "traditionally" obtained on machines with IDE drives. Most likely - with write cache, when the drive gets the data it puts it into cache and then says "yep all done" and you continue on as it puts it on the disk. But if the power goes out as it's doing that you got trouble. The difference between SCSI and IDE/SATA in this case is a lot if not all IDE/SATA drives tell you that the cache is disabled when you ask it to but they either don't actually disable it or they don't retain the setting so you get caught later. SCSI disks can be trusted when you set this option. > I wonder if running a machine on a UPS + 1 hot standby internal PS is > equivalent, in terms of data integrity, to using battery backed write > cache. Instinctively, I'd think that UPS + 1 hot standby internal PS > is better, since this setup also provides for the disk to actually > write out the content of the cache -- as you pointed out. > This is covering two different scenarios. The UPS maintains power in the event of a black out. The hot standby internal PS maintains power when the first PS dies. It is a good choice to have both as a PS dying will be just as bad as losing power without a UPS and the UPS won't save you if the PS goes. A battery backed raid card sits in between these - as long as the drive's write cache is off - the raid card will hold data that was sent to disk until it confirms it is written to disk. The battery backup will even hold that data until the machine is switched back on when it completes the writing to disk. That would cover you even if the PS goes. -- Shane Ambler pgSQL@Sheeky.Biz Get Sheeky @ http://Sheeky.Biz
On Tue, 2007-02-27 at 09:27 +0100, Peter Kovacs wrote:
> I wonder if running a machine on a UPS + 1 hot standby internal PS is
> equivalent, in terms of data integrity, to using battery backed write
> cache. Instinctively, I'd think that UPS + 1 hot standby internal PS
> is better, since this setup also provides for the disk to actually
> write out the content of the cache -- as you pointed out.
It's all about the degree of safety. A battery-backed cache on a RAID
controller sits below all of these points of failure:
* External power
* Power supply
* Operating system
and with proper system administration, can recover from any transient
errors in the above. Keep in mind that it can only recover from
transient failures: if you have a long blackout that outlasts your UPS
and cache battery, you can still have data loss. Also, you need a very
responsive system administrator that can make sure that data gets to
disk in case of failure.
Let's say you have a RAID system but you rely on the UPS to make sure
the data hits disk. Well, now if you have an OS crash (caused by another
piece of hardware failing, perhaps), you've lost your data.
If you can afford it (in terms of dollars or performance hit) go with
the safe solution.
Also, put things in context. The chances of failure due to these kinds
of things are fairly low. If it's more likely that someone spills coffee
on your server than the UPS fails, it doesn't make sense to spend huge
amounts of money on NVRAM (or something) to store your data. So identify
the highest-risk scenarios and prevent those first.
Also keep in mind what the cost of failure is: a few hundred bucks more
on a better RAID controller is probably a good value if it prevents a
day of chaos and unhappy customers.
Regards,
Jeff Davis
On Tue, 2007-02-27 at 13:23, Jeff Davis wrote: > Also, put things in context. The chances of failure due to these kinds > of things are fairly low. If it's more likely that someone spills coffee > on your server than the UPS fails, it doesn't make sense to spend huge > amounts of money on NVRAM (or something) to store your data. So identify > the highest-risk scenarios and prevent those first. > > Also keep in mind what the cost of failure is: a few hundred bucks more > on a better RAID controller is probably a good value if it prevents a > day of chaos and unhappy customers. Just FYI, I can testify to the happiness a good battery backed caching RAID controller can bring. I had the only server that survived a complete power grid failure in the data center where I used to work. A piece of wire blew out a power conditioner, which killed the other power conditioner, all three UPSes and the switch to bring the diesel generator online. the only problem the pgsql server had coming back up was that it had remote nfs mounts it used for file storage that weren't able to boot up fast enough so we just waited a few minutes and rebooted it. All of our other database servers had to be restored from backup due to massive data corruption because someone had decided that NFS mounts were a good idea under databases.
On Sun, Feb 25, 2007 at 23:11:01 +0100, Peter Kovacs <maxottovonstirlitz@gmail.com> wrote: > A related question: > Is it sufficient to disable write cache only on the disk where pg_xlog > is located? Or should write cache be disabled on both disks? With recent linux kernels you may also have the option to use write barriers instead of disabling caching. You need to make sure all of your stacked block devices will handle it and most versions of software raid (other than 1) won't. This won't be a lot faster, since at sync points the OS needs to order a cache flush, but it does give the disks a chance to reorder some commands in between flushes.
On Tue, Feb 27, 2007 at 15:35:13 +1030, Shane Ambler <pgsql@Sheeky.Biz> wrote: > > From all that I have heard this is another advantage of SCSI disks - > they honor these settings as you would expect - many IDE/SATA disks > often say "sure I'll disable the cache" but continue to use it or don't > retain the setting after restart. It is easy enough to tests if your disk lie about disabling the cache. I doubt that it is all that common for modern disks to do that.
On Wed, Feb 28, 2007 at 05:21:41 +1030, Shane Ambler <pgsql@Sheeky.Biz> wrote: > > The difference between SCSI and IDE/SATA in this case is a lot if not > all IDE/SATA drives tell you that the cache is disabled when you ask it > to but they either don't actually disable it or they don't retain the > setting so you get caught later. SCSI disks can be trusted when you set > this option. I have some Western Digital Caviars and they don't lie about disabling write caching.
Joshua D. Drake wrote: > Geoffrey wrote: >> Guillaume Smet wrote: >>> On 2/23/07, Geoffrey <esoteric@3times25.net> wrote: >>>> As I've heard. We're headed for 8 as soon as possible, but until we get >>>> our code ready, we're on 7.4.16. >>> You should move to at least 8.1 and possibly 8.2. It's not a good idea >>> to upgrade only to 8 IMHO. >> When I said 8, I meant whatever the latest greatest 8 is. Right now, >> that looks like 8.2.3. > > No. The latest version of 8.2 is 8.2.3, there is also 8.1 which is at > 8.1.8 and 8.0 which is at 8.0.12. > > They are all different *major* releases. Yes I am aware of the various releases. My bad in that my reference to '8' was lazy and did not indicate the full release. Our intention is to move to the latest 8.2.* when we are able. > IMO, nobody should be running anything less than 8.1.8. Same old thing, time and money. Too busy bailing the boat to patch it right now... -- Until later, Geoffrey Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin