On Mon, Sep 12, 2011 at 01:20:19PM +1000, Jason White wrote:
> Regarding ZFS, it is my impression that all of the people who
> understand the internals of the file system and its implementation
> are Sun/Solaris developers, some of whom may have left after the
> acquisition by Oracle. I don't know what situation this creates as to
> the availability of expertise (at the level of understanding the code
> well enough to debug it) for projects porting it to BSD and Linux.
many of them now work on the same code at Joyent or Nexenta and similar
And it looks like they, through the Illumos community, will end up
forking OpenSolaris (incl. ZFS and other solaris goodies) by default if
Oracle doesn't start actively participating.
LLNL, who are working on the zfsonlinux port, are also involved in
the Illumos-centred ZFS development.
Disclaimer: nothing past my first paragraph is "fact". it's just my 2c
summary/interpretation of various things i've read on various web sites
and mailing list archives.
craig sanders <cas(a)taz.net.au>
BOFH excuse #148:
Insert coin for new game
I had anew message from the list (James Harper), but it didn't get to
the right folders via my rules in my .forward -- this seems to be due to
the List-Id head being different, possibly running over two lines?
List-Id: "Main LUV community and support mailing list."
This from my .forward
$h_List-Id: matches "luv-main.luv.asn.au"
Hmm, okay it might not be multi-line issue, but still a change?
Are other lists changing this way? Was this an error?
Can you guys stop these excess LUV emails.. ?
I was on the LUV list and got about 3-4 emails per week... OK..
Now its suddenly about 40 per day... Seems like something has gone
astray with the email system...
> On Thu, 15 Sep 2011, Erik Christiansen <dvalin(a)internode.on.net> wrote:
> > As craig suggested, it'd be very nifty, though, if we could lose the
> > "[luv-main]" pollution in the Subject header. The plethora of list
> > headers on which to filter, make it entirely redundant.
> Also mangling the subject breaks DKIM in almost all cases as the
> signed in all typical configurations. Appending a footer doesn't
> break things as the signer can use the l= flag.
> My Main Blog http://etbe.coker.com.au/
> My Documents Blog http://doc.coker.com.au/
> luv-main mailing list
Message sent using MelbPC WebMail Server
I have received 47 messages from luv-main in my main account address -
But I have received the same messages in my secondary address as well -
This is new behaviour.
Not grumpy, just informative. I am grateful for all of the work that
goes into keeping us informed.
Quoting "Chris Samuel" <chris(a)csamuel.org>:
> On Mon, 12 Sep 2011 10:32:43 AM Peter Ross wrote:
>> Quoting "Andrew McGlashan" <andrew.mcglashan(a)affinityvision.com.au>:
>> > including a working fsck ability, which is essential.
>> It's overrated;-)
> Not on an experimental filesystem which can have some, umm,
> interesting bugs at times.. ;-)
The fsck looks more magic than everything else to me (because it has
to catch "the unexpected") and if you try "magic" on something that is
not fully understood yet.. good luck with that.
I see your point.
At the moment I go for plan B first (backup/failover) instead of
praying that magic helps me if it goes pear-shaped.
In that sense it may be a waste of time to write a fsck. However, I
can imagine that it helps you to improve the original code. If you
write fsck you have to think about "what can go wrong" - and then you
are half-way through to fix it (and not relying on fsck).
I always avoid software that needs "repair tools" in production. E.g.
I hated to work with MySQL 3 and having to fix MyISAM tables and
indexes if something went wrong.
It took me a while until I wanted to touch MySQL again.. These days I
do not even remember what the repair tools look like, and I hope I
never have to google for it.
On Sat, 10 Sep 2011 08:50:43 PM Chris Samuel wrote:
> FWIW I attach my homegrown zsnapshot and bsnapshot scripts
> in case they are of use.. GPLv3 or later.
I've now stopped using ZFS/FUSE and moved to the "ZFS on Linux"
DKMS version instead as it seems to be progressing well, so I've
modified the zsnapshot script to just use zfs mount/umount.
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP
Up until a few minutes ago, I was getting both LUV Main and LUV Talk in
digest mode only. In the last few minutes, I have started to receive
unbundled messages to LUV Main and on logging into the mailman page, saw
that Digest mode was turned off. I have since enabled Digest again.
Has something happened with the listserver, or was it just me ?
"Computers are incredibly fast, accurate, and stupid;
Humans are incredibly slow, inaccurate and brilliant.
Together they are powerful beyond imagination."
A committee is a cul-de-sac, down which ideas are lured and then quietly
*Sir Barnett Cocks<http://www.quotationspage.com/quotes/Sir_Barnett_Cocks/>
"A mind is like a parachute. It doesnt work if it's not open." :- Frank
At 06:33 PM 9/14/2011, Tim Connors wrote:
>And that damn "[luv-main]" text has been prepended by stealth after years
>of arguing for and against. Someone cared so much about it that they
>killed the hardware just so they could slip this in? :P
Yeah, I did see that. Was a bit like the Spanish Inquisition - I
wasn't expecting it :D
>(can we fix that setting, pretty please? procmail can easily filter posts
>into folders without that, but can't strip the useless text out of the
>subject line, at least reliably, and guaranteed to work no matter how
>many times the thread bounces back and forth between luv-main and
>luv-talk, and how many times people change the subject line of a thread.)
Some good points there. Personally, it's never been a big issue for
me either way, and even less so now that I've finally got around to
filtering on the right header :)
73 de VK3JED / VK3IRL
I'm testing multipath with iscsi now, and having the multipath
infrastructure present means that the actual iscsi device is unusable,
you have to go through the multipath device node. This makes perfect
sense exact that pacemaker wants to mount the filesystem before
multipath has created the device node.
I notice there is a Delay agent, but that seems like a bit of a hack -
how much of a delay is enough, without waiting unnecessarily long?
This is a followup to my nfs or ocfs2 question... it turns out that nfs
failover doesn't work that smoothly due to hanging tcp connections and
holding the block device open so I've gone with ocfs2.