ext3 barrier=1 ???
Mike Jones
Found this on wikipedia...
===========================
Ext3 does not do checksumming when writing to the journal. If barrier=1
is not enabled as a mount option (in /etc/fstab), and if the hardware is
doing out-of-order write caching, one runs the risk of severe filesystem
corruption during a crash.[22][23]
Consider the following scenario: If hard disk writes are done out-of-
order (due to modern hard disks caching writes in order to amortize write
speeds), it is likely that one will write a commit block of a transaction
before the other relevant blocks are written. If a power failure or
unrecoverable crash should occur before the other blocks get written, the
system will have to be rebooted. Upon reboot, the file system will replay
the log as normal, and replay the "winners" (transactions with a commit
block, including the invalid transaction above which happened to be
tagged with a valid commit block). The unfinished disk write above will
thus proceed, but using corrupt journal data. The file system will thus
mistakenly overwrite normal data with corrupt data while replaying the
journal. There is a test program available to trigger the problematic
behavior. If checksums had been used, where the blocks of the "fake
winner" transaction were tagged with a mutual checksum, the file system
could have known better and not replayed the corrupt data onto the disk.
Journal checksumming has been added to EXT4.[24]
The ext3 barrier option is not enabled by default on almost all popular
Linux distributions[citation needed] except openSUSE, and thus most
distributions are at risk. In addition, filesystems going through the
device mapper interface (including software RAID and LVM implementations)
may not support barriers, and will issue a warning if that mount option
is used.[25][26] There are also some disks that do not properly implement
the write cache flushing extension necessary for barriers to work, which
causes a similar warning.[27] In these situations, where barriers are not
supported or practical, reliable write ordering is possible by turning
off the disk's write cache and using the data=journal mount option.[28]
Turning off the disk's write cache may be required even when barriers are
available. Applications like databases expect a call to fsync() will
flush pending writes to disk, and the barrier implementation doesn't
always clear the drive's write cache in response to that call.[29] There
is also a potential issue with the barrier implementation related to
error handling during events such as a drive failure[30]
===========================
I'm wondering if I should be playing with this. What are the benefits,
the disadvantages, the SNAFUs if an enthusiastic dabbler plays around
with such magic? ;)
Then there is the question "Why isn't this enabled by default?" and the
other "Why isn't it in the man pages?"
I'm sorely tempted to mess about with this, even though I don't know if
it would do me or my system any good.
Anybody want to go "OMGs! Noooooo! Don't use that because...!" about here?
The wisdoms of the Slackware magii, as always, are welcome at this point.
--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
Grant
>
>
>Found this on wikipedia...
...
>I'm sorely tempted to mess about with this, even though I don't know if
>it would do me or my system any good.
>
>Anybody want to go "OMGs! Noooooo! Don't use that because...!" about here?
Dunno, after ext3 locked up on me a couple times I switched to reiserfs3,
no problems since.
They've introduced ext4 to have a another go at fixing ext2 :)
Grant.
--
http://bugsplatter.id.au
Mike Jones
Are you sure that was an ext3 problem? Did you try dropping it back to
ext2 to recover, for instance? I'm looking for your overall impressions
here. Do you really think ext3 has "fatal flaw" problems, or was your
switch a matter of just finding the quickest route to system stability?
I'm still curious as to why the info about the barrier=1 flag never made
it to the man pages. This indicates a lack of attention to detail in a
project that gives me cause for concern. Reiserfs caught my eye, but
SUSE's dropping of it as a "not-predictably-developed" project put me off
switching to it, and their switching to ext3 instead of JFS or XFS
indicated to me that ext3 would be the choice for stability and
reliability.
I'm thinking that the default ext3 setup is probably the most reliable.
I also note a few comments here and there regarding ext4's BETA status,
despite it now being deployed to some degree.
What to do? Hmmm.
Douglas Mayne
Caveat: I am not using ext3, ext4.
This is also an interesting article pointing in the direction of
future filesystem development:
http://en.wikipedia.org/wiki/Btrfs
I will probably switch to btrfs, mostly to get the advanced snapshot
capability, as soon as it is "ready."
Personally, I have been using XFS for years. AFAIK, it has some of the
same crash coherency issues that you referenced with ext4. There
is a recommended cache setting to use as a potential workaround. Luckily,
Linux doesn't crash much. However, I had some crashes under 2.6.30.x.
Originally, I had attributed the crashes to the r8169 network module, but
I think the hard crashes were really attributable to a flaw in XFS and
SMP, as noted in the kernel changelog. The only other potential problem
with XFS is some performance issues when making large changes to the
filesystem, especially, when deleting top-level tree branches.
I also thought about switching some boxes over to OpenSolaris to get ZFS.
So far, I have found it too different. That is, it doesn't leverage
the command set from GNU/Linux. I guess the divergence is a by-product of
*nix fragmentation. I have also seen reports off poor performance and
stability issues with ZFS. Apple dropping support for it raises a big
question mark in my mind, as one would think that OS X could benefit from
the advanced features. All of this keeps me hoping that btrfs
will eventually be released and deliver on its promises.
--
Douglas Mayne
Mike Jones
It seems as if we're in a time of *NIX-flux again. Maybe its a good time
to just sit back with the defaults until the new standards emerge?
FWIW, I just managed to crash a new box today (dodgy power cable fell out
while fitting it) and the ext3fs just picked it up on reboot with hardly
more than a couple of seconds delay in booting.
The only concern that seems worth attention with ext3 ATM is the possible
SNAFUs if a crash occurs during an overwrite operation, which, seeing as
I keep a restore backup of my active OS handy, and the userbase will only
be transfering files rather than overwriting them, maybe nothing to worry
about right now?
Keith Keller
>
> I'm still curious as to why the info about the barrier=1 flag never made
> it to the man pages. This indicates a lack of attention to detail in a
> project that gives me cause for concern.
Perhaps you should ask the maintainers of the ext4 documentation?
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Keith Keller
> On 2009-12-06, Mike Jones <N...@Arizona.Bay> wrote:
>>
>> I'm still curious as to why the info about the barrier=1 flag never made
>> it to the man pages. This indicates a lack of attention to detail in a
>> project that gives me cause for concern.
>
> Perhaps you should ask the maintainers of the ext4 documentation?
Or extN, where N is the version of ext that concerns you.
Joe
> Personally, I have been using XFS for years.
I switched from Reiser4 to XFS.
> I also thought about switching some boxes over to OpenSolaris to get ZFS.
> So far, I have found it too different. That is, it doesn't leverage
> the command set from GNU/Linux. I guess the divergence is a by-product of
> *nix fragmentation. I have also seen reports off poor performance and
> stability issues with ZFS.
ZFS works fine in my experience. We have a couple of Solaris boxes at work, with
ZFS. Seems Sun managed to get rid of the Slowlaris moniker.
> Apple dropping support for it raises a big
> question mark in my mind
My understanding is that this was more of a licensing issue.
Grant
>Responding to Grant:
>
>> On Sat, 05 Dec 2009 13:19:37 GMT, Mike Jones <N...@Arizona.Bay> wrote:
>>
>>
>>>
>>>Found this on wikipedia...
>> ...
>>>I'm sorely tempted to mess about with this, even though I don't know if
>>>it would do me or my system any good.
>>>
>>>Anybody want to go "OMGs! Noooooo! Don't use that because...!" about
>>>here?
>>
>> Dunno, after ext3 locked up on me a couple times I switched to
>> reiserfs3, no problems since.
>>
>> They've introduced ext4 to have a another go at fixing ext2 :)
>>
>> Grant.
>
>
>Are you sure that was an ext3 problem? Did you try dropping it back to
>ext2 to recover, for instance? I'm looking for your overall impressions
>here. Do you really think ext3 has "fatal flaw" problems, or was your
>switch a matter of just finding the quickest route to system stability?
The ext3 lockups were years ago, when I was running redhat, as for
recovery, a reboot was required, there was no filesystem damage.
No doubt this ext3 issue was fixed in the kernel. But I switched
to reiserfs3 back then and stayed with it. No more waiting for
fsck every couple dozen boots.
And yes, switching to reiserfs3 was the quickest way to system
stability for boxes running sans UPS.
>
>I'm still curious as to why the info about the barrier=1 flag never made
>it to the man pages. This indicates a lack of attention to detail in a
>project that gives me cause for concern.
I skim the linux-kernel list for years, my impression is that write
barriers are still to be guaranteed. Seems ext3 has subtle bugs that
surface so rarely nobody can fix them. Documentation is the weak
point in free software -- little incentive to write it as the people
always say --> 'you have the source'...
> Reiserfs caught my eye, but
>SUSE's dropping of it as a "not-predictably-developed" project put me off
>switching to it, and their switching to ext3 instead of JFS or XFS
>indicated to me that ext3 would be the choice for stability and
>reliability.
Suse stabilised reiserfs3 for production use, and the people with that
filesystem knowledge moved onto better things
>
>I'm thinking that the default ext3 setup is probably the most reliable.
For now on small boxes without UPS, perhaps, though reiserfs3 I think
is better.
>
>I also note a few comments here and there regarding ext4's BETA status,
>despite it now being deployed to some degree.
It's the current default FS for slackware and some other distros.
Grant.
--
http://bugsplatter.id.au
Grant
>On Sun, 06 Dec 2009 11:42:05 +0000, Mike Jones wrote:
>
...
>This is also an interesting article pointing in the direction of
>future filesystem development:
>http://en.wikipedia.org/wiki/Btrfs
Nice read, lead developer Chris Mason is one of the people stabilised
resierfs3 when he was at Suse, so I guess Chris knows what is needed
in a decent FS.
>
>I will probably switch to btrfs, mostly to get the advanced snapshot
>capability, as soon as it is "ready."
Yes, an FS design sponsered by Oracle would have to perform well.
>
>Personally, I have been using XFS for years. AFAIK, it has some of the
>same crash coherency issues that you referenced with ext4. There
>is a recommended cache setting to use as a potential workaround. Luckily,
>Linux doesn't crash much. However, I had some crashes under 2.6.30.x.
Problem for many is not Linux crashing per se, it's the unexpected
power failure for small systems or media failure in large (RAID)
systems that cause the tropuble.
>Originally, I had attributed the crashes to the r8169 network module, but
>I think the hard crashes were really attributable to a flaw in XFS and
>SMP, as noted in the kernel changelog. The only other potential problem
>with XFS is some performance issues when making large changes to the
>filesystem, especially, when deleting top-level tree branches.
Plus the need for UPS as XFS is a 'big iron' FS that keeps much state
data in memory. It is also a deep stack user which means the FS can
suffer from other deep stack users, for example a poorly written
device driver using too much stack might cause damage.
>
>I also thought about switching some boxes over to OpenSolaris to get ZFS.
Drastic, GNU/Linux will get there, given some time.
Grant.
--
http://bugsplatter.id.au
Mike Jones
> On 2009-12-06, Mike Jones <N...@Arizona.Bay> wrote:
>>
>> I'm still curious as to why the info about the barrier=1 flag never
>> made it to the man pages. This indicates a lack of attention to detail
>> in a project that gives me cause for concern.
>
> Perhaps you should ask the maintainers of the ext4 documentation?
>
> --keith
Heh! :)
Mike Jones
[...]
>>I'm thinking that the default ext3 setup is probably the most reliable.
>
> For now on small boxes without UPS, perhaps, though reiserfs3 I think is
> better.
As I've now got every box on the LAN running ext3, I think I'll let it
run for a while. I've only lost data once in over 10 years with ext2, so
ext3 should reduce that risk tolerably for now.
That btfs is looking pretty interesting.
Grant
>Responding to Grant:
>
>[...]
>>>I'm thinking that the default ext3 setup is probably the most reliable.
>>
>> For now on small boxes without UPS, perhaps, though reiserfs3 I think is
>> better.
>
>
>As I've now got every box on the LAN running ext3, I think I'll let it
>run for a while. I've only lost data once in over 10 years with ext2, so
>ext3 should reduce that risk tolerably for now.
Oh sure -- I wouldn't change filesystems unless there was a problem to
resolve.
>
>That btfs is looking pretty interesting.
Yes.
Grant.
--
http://bugsplatter.id.au
+Alan Hicks+
Hash: SHA1
Slightly off-topic; I apologize. :^)
On 2009-12-06, Grant <g_r_a...@bugsplatter.id.au> wrote:
> Dunno, after ext3 locked up on me a couple times I switched to reiserfs3,
> no problems since.
I've run reiserfs on more different machines than most people. About a
year to a year and a half back I switched away from reiserfs to xfs and
ext3. I worked with JFS for a little while, and I'm currently using
ext4 on my laptop. I've yet to find a filesystem that I 100% like in
all situations, so here's my take on all the different ones.
ext2 - Not much to say here. It's the "VFAT" of the Linux world.
Stable, simple, decent speed, and lots of recovery tools if something
goes wrong. Without journaling though, it's a PITA on large disks when
there's some sort of crash or power failure. ext2 was great when the
largest disks most people had were 8GB in size. On modern drives, ext2
should almost never be used. It does however, have some slight speed
performances compared to our next contender.
ext3 - Successor to ext2, and it looks like one. Pretty much all the
benefits of ext2 with some improvements both large and small. The big
one of course, is journaling. Now when the machine crashes, you don't
have to spend an hour waiting on that 320GB /home partition to fsck.
ext3 isn't as fast as ext2 in the performance tests I've seen, but for
most work, it seems solid and fast. I've never noticed a "seat of the
pants" performance loss when using ext3 compared to ext2. Today, if you
want reliability over everything else, I think ext2 is what you should
use. The real pain are the mandatory fscks every 30 or so mounts. True,
you can disable this, but it's really not recommended that you do so.
ext3 like ext2 needs to be fsck'd occassionally to ensure that it
doesn't suffer corruption.
reiserfs - I've run this filesystem more than all the others combined.
I started using it with Slackware 8.0 and kept using it until around
mid-way through Slackware 12.2. In all the tests I've performed, it is
clearly the fastest filesystem available today, particularly when
dealing with lots of small files. I moved away from reiserfs after I
started finding filesystem corruption on a few machines. One machine in
particular was located at a colo, and this made rectifying the problem
incredibly difficult. FWIW, we ran that machine for perhaps a year with
this corrupted /home filesystem without any real problems, but it was
scary enough to make myself and others reconsider using resierfs on
colo'd boxen. I will still use reiserfs occassionally today whenever it
makes sense to do so. If you need fast read and write support,
particularly with loads of small files and data reliability isn't 100%
required, reiserfs makes a lot of sense. I occassionally use it on /var
for mail servers (especially ones using maildir) for this very reason.
jfs - I used this on may laptop for awhile with Slackware 12.0 and
12.1. I was not overly impressed with it. In fact, I think it's safe to
say that I was underwhelmed. I had several issues with the filesystem.
If the laptop crashed (which happened about 1 in every 10 times
suspending the machine), fsck couldn't properly identify the
filesystems as jfs, and thus couldn't check them or mount them. I've
heard of other people running into similar problems. My performance
tests didn't overly impress me either.
xfs - I don't have a lot to say about this filesystem. I've used it in
several places and it performs well, but I'm still a little bit leary
of using it without good UPS. xfs was designed for "big iron" machines
with disk controllers that came with capacitors so large they could
virtually garauntee that any write operation completed, even after the
power was cut to the machine. Typical PC hardware can't make this same
garauntee, and I'm not certain that the filesystem has been modified to
fully account for such contingencies.
ext4 - Don't use it unless you're willing to loose data. So far I
haven't had any problems with it, but I also don't do lots of writes to
this filesystem. It's not one I would trust with important data for
some time to come.
btrfs - Haven't used it, but I've read a lot. Everything I read says
it's the "wave of the future". Only time will really tell. I remember
people saying the same things about reiserfs v4 and it's pluggable
architecture, but reiser4 is basically dead now and truth be told, had
stalled long before Hans murdered his wife. btrfs has a lot of promise,
but it's still highly experimental, evolving daily, and not for the
casual Linux user to consider.
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksdPWsACgkQNj1TaGS9H5IPfACfXrd0Hn2ncELtzL2oEXyVwTDW
ySoAoJPiueHXsU7GC+FvhXBeRVWWvt9/
=jBAA
-----END PGP SIGNATURE-----
Grant
...
>Slightly off-topic; I apologize. :^)
OT on _this_ group? Nah...
[snip good filesystem summary]
Ext2/3 have the excellent data safety and recovery options, reiserfs is
basically non-repairable if on-disk structures get corrupted.
Ext4 needs more end-user testing, but that's for the Fedora crowd,
Redhat's beta-testers :)
Grant.
--
http://bugsplatter.id.au
r...@realtomargarino.ca
Oh, joy!
pgp trash troll delete
> I've run reiserfs on more different machines than most people.
Who set them up for you?
> About a year to a year and a half back
Was that about the time that PV was sick and you tried to hijack the
distro?
And don't play dumb, asshole. We all remember and it was truly sad.
> I switched away from reiserfs to xfs and ext3.
How much did it cost you to swith back?
> I worked with JFS for a little while, and I'm currently using
> ext4 on my laptop. I've yet to find a filesystem that I 100% like in
> all situations, so here's my take on all the different ones.
Great stuff! The original Hillbilly Hicks speaks:
> ext2 - Not much to say here. It's the "VFAT" of the Linux world.
> Stable, simple, decent speed, and lots of recovery tools if something
> goes wrong. Without journaling though, it's a PITA on large disks when
> there's some sort of crash or power failure. ext2 was great when the
> largest disks most people had were 8GB in size. On modern drives, ext2
> should almost never be used. It does however, have some slight speed
> performances compared to our next contender.
Crash or power failure? Would that include bouncing around the back
of your cousin's 20 year old pickup truck on the way to Atlanta's
famous "Bill Maynard's New and Used Computers?"
Perhaps if you had taken the rifle and Old Dixie down from the back
window of the truck you might have been able to see the drives
bouncing around back there like a bunch of rusty old horseshoes?
> ext3 - Successor to ext2,
Wow. 3 comes after 2. And you actually _knew_ that!
> and it looks like one. Pretty much all the benefits of ext2 with
> some improvements both large and small. The big one of course, is
> journaling. Now when the machine crashes, you don't have to spend
> an hour waiting on that 320GB /home partition to fsck. ext3 isn't
> as fast as ext2 in the performance tests I've seen,
And what tests would those be? You and cousin Jed standing by with
your thumbs on those large buttons on your fake Rolexes?
Or does Jed use a fake Timex?
> but for most work, it seems solid and fast. I've never noticed a
> "seat of the pants" performance loss when using ext3 compared to
Yeah, but were you wearing underwear under those overalls? Perhaps
we're asking if you did the test on Sunday?
> ext2. Today, if you want reliability over everything else, I think
> ext2 is what you should use. The real pain are the mandatory fscks
> every 30 or so mounts.
How many times a day do you and Jed hit the 30 mount point? Or
would that be the 30 point mount? And if the latter, would that be
with the overalls up or down?
> True, you can disable this, but it's really not recommended that
> you do so. ext3 like ext2 needs to be fsck'd occassionally to
> ensure that it doesn't suffer corruption.
Hell, you might just as well turn the whole damned works off and save the
electricity. Give those windmills a break. Those computers look
just as good off or on anyway - and the Sinclairs don't even have
hard drives.
> reiserfs - I've run this filesystem more than all the others combined.
German, eh? Those Germans always make good stuff.
> I started using it with Slackware 8.0 and kept using it until
> around mid-way through Slackware 12.2. In all the tests I've
> performed, it is clearly the fastest filesystem available today,
> particularly when dealing with lots of small files.
We're curious. We know you've got the fake Timex to measure the
speed but how did you measure the file size? Tape measure?
Yardstick? Or did you just pace it off?
> I moved away from reiserfs after I started finding filesystem
> corruption on a few machines.
That would have been the Sinclairs. That wasn't file corruption,
lugan. It was the fact that you probably moved the Sinclairs. We
are surprised that after all these years working with those
Sinclairs you didn't know that you have to crazy glue that daisy
chain together.
Where is Keith Creller when you need him, anyway? He knows all
about that stuff. In fact, he runs the biggest Sinclair parts depot
on the West Coast!
> One machine in particular was located at a colo, and
> this made rectifying the problem incredibly difficult. FWIW, we
> ran that machine for perhaps a year with this corrupted /home
> filesystem without any real problems, but it was scary enough to
> make myself and others reconsider using resierfs on colo'd boxen.
We remember once you glued two Sinclairs together. You told us that
one was to run the CPU while the other was to manage the memory.
But the two got confused and neither could remember what the other
was supposed to do. We told you that it was a race condition but
you disagreed, pointing out that both Sinclairs were black.
> I will still use reiserfs occassionally today whenever it makes
Those Germans always make good stuff.
> sense to do so. If you need fast read and write support,
Fast read and write? So you would have to call the wife in? Or was
this before you married her and she was still your sister?
> particularly with loads of small files and data reliability isn't
> 100% required, reiserfs makes a lot of sense. I occassionally use
> it on /var for mail servers (especially ones using maildir) for
> this very reason.
You like the Male Servers better, do you? They still have
the Chippendales in every thursday night at "Bill Maynard's
New and Used Computers?"
> jfs - I used this on may laptop
On your lap? Is JFS one of the male server's initials?
> for awhile with Slackware 12.0 and 12.1. I was not overly
> impressed with it. In fact, I think it's safe to say that I was
> underwhelmed.
Well, sure. After you've been with Cousin Jed the rest just don't
measure up.
> I had several issues with the filesystem.
> If the laptop crashed (which happened about 1 in every 10 times
> suspending the machine), fsck couldn't properly identify the
> filesystems as jfs, and thus couldn't check them or mount them. I've
> heard of other people running into similar problems. My performance
> tests didn't overly impress me either.
You shouldn't have left it on your lap while JFS danced. Hell, even
with your tiny pecker things can get moved around. You know that.
> xfs - I don't have a lot to say about this filesystem. I've used it in
XFS? Is that JFS's bro?
> several places and it performs well, but I'm still a little bit leary
> of using it without good UPS. xfs was designed for "big iron" machines
Like Jed?
> with disk controllers that came with capacitors so large they could
> virtually garauntee that any write operation completed, even after the
> power was cut to the machine. Typical PC hardware can't make this same
> garauntee, and I'm not certain that the filesystem has been modified to
> fully account for such contingencies.
You got to learn to stretch that filesystem gradually and gently.
> ext4 - Don't use it unless you're willing to loose data.
After all those years of constipation? Wouldn't you be raring to
go?
> So far I haven't had any problems with it, but I also don't do
> lots of writes to this filesystem. It's not one I would trust with
> important data for some time to come.
Damn, all you have to do is glue those Sinclair together. You'd be
amazed at the difference!
> btrfs - Haven't used it, but I've read a lot. Everything I read says
> it's the "wave of the future". Only time will really tell. I remember
> people saying the same things about reiserfs v4 and it's pluggable
> architecture, but reiser4 is basically dead now and truth be told, had
> stalled long before Hans murdered his wife. btrfs has a lot of promise,
> but it's still highly experimental, evolving daily, and not for the
> casual Linux user to consider.
And that would be why you haven't yet considered it, right doofus?
pgp trash troll delete
And it was certainly much more fun than punching the shit out of Lew
Pitcher again...
cordially, as always,
rm
Mike Jones
Nice review there.
Cheers! :)
+Alan Hicks+
Hash: SHA1
On 2009-12-07, r...@realtomargarino.ca <r...@realtomargarino.ca> wrote:
> We remember once you glued two Sinclairs together. You told us that
> one was to run the CPU while the other was to manage the memory.
> But the two got confused and neither could remember what the other
> was supposed to do. We told you that it was a race condition but
> you disagreed, pointing out that both Sinclairs were black.
</modquote>
Congrats, RM. One of the funniest things I've read here in a long time.
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkshgD4ACgkQNj1TaGS9H5JWUwCgr+qdcEw9Efz9Q3no7Cnr/22N
Yn8An2Zcpqjxm5bl1VjxNrVw33dPAnmk
=qrXN
-----END PGP SIGNATURE-----
Lew Pitcher
pgp trash troll delete
> On 2009-12-07, r...@realtomargarino.ca <r...@realtomargarino.ca> wrote:
>> We remember once you glued two Sinclairs together. You told us that
>> one was to run the CPU while the other was to manage the memory.
>> But the two got confused and neither could remember what the other
>> was supposed to do. We told you that it was a race condition but
>> you disagreed, pointing out that both Sinclairs were black.
> </modquote>
>
> Congrats, RM. One of the funniest things I've read here in a long time.
Well, thanks, I guess. I really thought that all of those who
might have "gotten" it have me buried deep in killfile country...
Where is Faux_Pseudo these days, anyway? Isn't he supposed to be
keeping track of this stuff?
cordially, as always,
rm
Robby Workman
> +Alan Hicks+ <al...@lizella.network> trolled:
>
> pgp trash troll delete
>
>> On 2009-12-07, r...@realtomargarino.ca <r...@realtomargarino.ca> wrote:
>>> We remember once you glued two Sinclairs together. You told us that
>>> one was to run the CPU while the other was to manage the memory.
>>> But the two got confused and neither could remember what the other
>>> was supposed to do. We told you that it was a race condition but
>>> you disagreed, pointing out that both Sinclairs were black.
>> </modquote>
>>
>> Congrats, RM. One of the funniest things I've read here in a long time.
>
> Well, thanks, I guess. I really thought that all of those who
> might have "gotten" it have me buried deep in killfile country...
I thought it was pretty good too, but I rarely reply to *anyone*
to only say "haha" :-)
-RW
Lew Pitcher
First the Hillbilly and now Package-boy... you guys are trying to
destroy our repuation?
cordially, etc.,
rm
A Guy Called Tyketto
Hash: SHA1
Actually, that one was really good! congrats.
Now shut your Canadian pie hole and bring me my Coffee Crisps!
Wench. ;)
BL.
- --
Brad Littlejohn | Email: tyk...@sbcglobal.net
Unix Systems Administrator, | tyk...@ozemail.com.au
Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto
PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQFLIcg4yBkZmuMZ8L8RArqKAKCdNkrdMOj0ldms8o+sFpKq4c1+FQCgr+yw
9i0xCvkEYxBXpbFE5jVKK0g=
=as6P
-----END PGP SIGNATURE-----
Robby Workman
Yes. We're also trying to teach a cat how to meow, a dog how to bark,
and get Kourtney Kardashian pregnant. ;-)
-RW
Loki Harfagr
> +Alan Hicks+ <al...@lizella.network> trolled:
>
> pgp trash troll delete
>
>> On 2009-12-07, r...@realtomargarino.ca <r...@realtomargarino.ca> wrote:
>>> We remember once you glued two Sinclairs together. You told us that
>>> one was to run the CPU while the other was to manage the memory. But
>>> the two got confused and neither could remember what the other was
>>> supposed to do. We told you that it was a race condition but you
>>> disagreed, pointing out that both Sinclairs were black.
>> </modquote>
>>
>> Congrats, RM. One of the funniest things I've read here in a long time.
>
> Well, thanks, I guess. I really thought that all of those who might
> have "gotten" it have me buried deep in killfile country...
not exactly, I confess I read your text twice laughing quite a lot
and saved it to read it again on a rainy day then intended to post
an applause and a |\/|odquote but decided that as the text though
hilarious (to me) was also an ad hominem assault then discarded my
concretulating post.
> Where is Faux_Pseudo these days, anyway? Isn't he supposed to be
> keeping track of this stuff?
last news (on the Net) were old and he was urgently looking for some work
while having his coming out as a MacOS man, wonder if both troubles are
now cured.
Chick Tower
> Yes. We're also trying to teach a cat how to meow, a dog how to bark,
> and get Kourtney Kardashian pregnant. ;-)
That was you????
--
Chick Tower
For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net
Keith Keller
> On 2009-12-11, Robby Workman <newsg...@rlworkman.net> wrote:
>> Yes. We're also trying to teach a cat how to meow, a dog how to bark,
>> and get Kourtney Kardashian pregnant. ;-)
>
> That was you????
OH MY GOD I thought the new Subject was referring to me. Yikes!
(It's not, right? RIGHT?!?)
Loki Harfagr
> On 2009-12-12, Chick Tower <c.t...@deadspam.com> wrote:
>> On 2009-12-11, Robby Workman <newsg...@rlworkman.net> wrote:
>>> Yes. We're also trying to teach a cat how to meow, a dog how to bark,
>>> and get Kourtney Kardashian pregnant. ;-)
>>
>> That was you????
>
> OH MY GOD I thought the new Subject was referring to me. Yikes!
>
> (It's not, right? RIGHT?!?)
well, as Ian Gillan once sang
"We really didn't know you'd had it in you" ;-)
Now, who the hell is that unknowmn item "Kourtney Kardashian"?