Ok, thanks everyone then (but still thanks to Victor for the heads up) :-)
On Mon, Nov 2, 2009 at 4:03 PM, Victor Latushkin
wrote:
> On 02.11.09 18:38, Ross wrote:
>>
>> Double WOHOO! Thanks Victor!
>
> Thanks should go to Tim Haley, Jeff Bonwick and George Wilson ;-)
>
___
Yup, somebody pointed that out to me last week and I can't wait :-)
On Wed, Jul 29, 2009 at 7:48 PM, Dave wrote:
> Anyone (Ross?) creating ZFS pools over iSCSI connections will want to pay
> attention to snv_121 which fixes the 3 minute hang after iSCSI disk
> problems:
>
> http://bugs.opensolari
where somebody used mdb to search a
corrupt pool to try to recover data:
http://opensolaris.org/jive/message.jspa?messageID=318009
On Fri, Feb 13, 2009 at 11:09 PM, Richard Elling
wrote:
> Tim wrote:
>>
>>
>> On Fri, Feb 13, 2009 at 4:21 PM, Bob Friesenhahn
>> mailto:bf
t more time should recovery be needed.
On Fri, Feb 13, 2009 at 8:59 PM, Bob Friesenhahn
wrote:
> On Fri, 13 Feb 2009, Ross Smith wrote:
>
>> Thinking about this a bit more, you've given me an idea: Would it be
>> worth ZFS occasionally reading previous uberblocks from the
On Fri, Feb 13, 2009 at 8:24 PM, Bob Friesenhahn
wrote:
> On Fri, 13 Feb 2009, Ross Smith wrote:
>>
>> You have to consider that even with improperly working hardware, ZFS
>> has been checksumming data, so if that hardware has been working for
>> any length of time, you
On Fri, Feb 13, 2009 at 8:24 PM, Bob Friesenhahn
wrote:
> On Fri, 13 Feb 2009, Ross Smith wrote:
>>
>> You have to consider that even with improperly working hardware, ZFS
>> has been checksumming data, so if that hardware has been working for
>> any length of time, you
On Fri, Feb 13, 2009 at 7:41 PM, Bob Friesenhahn
wrote:
> On Fri, 13 Feb 2009, Ross wrote:
>>
>> Something like that will have people praising ZFS' ability to safeguard
>> their data, and the way it recovers even after system crashes or when
>> hardware has gone wrong. You could even have a "comm
That would be the ideal, but really I'd settle for just improved error
handling and recovery for now. In the longer term, disabling write
caching by default for USB or Firewire drives might be nice.
On Thu, Feb 12, 2009 at 8:35 PM, Gary Mills wrote:
> On Thu, Feb 12, 2009 at 11:53:40AM -0500, G
Heh, yeah, I've thought the same kind of thing in the past. The
problem is that the argument doesn't really work for system admins.
As far as I'm concerned, the 7000 series is a new hardware platform,
with relatively untested drivers, running a software solution that I
know is prone to locking up
ve
that is how often the cache should be writing).
On Fri, Feb 6, 2009 at 7:04 PM, Brent Jones wrote:
> On Fri, Feb 6, 2009 at 10:50 AM, Ross Smith wrote:
>> I can check on Monday, but the system will probably panic... which
>> doesn't really help :-)
>>
>> Am I
I can check on Monday, but the system will probably panic... which
doesn't really help :-)
Am I right in thinking failmode=wait is still the default? If so,
that should be how it's set as this testing was done on a clean
install of snv_106. From what I've seen, I don't think this is a
problem wi
It's not intuitive because when you know that -o sets options, an
error message saying that it's not a valid property makes you think
that it's not possible to do what you're trying.
Documented and intuitive are very different things. I do appreciate
that the details are there in the manuals, but
That's my understanding too. One (STEC?) drive as a write cache,
basically a write optimised SSD. And cheaper, larger, read optimised
SSD's for the read cache.
I thought it was an odd strategy until I read into SSD's a little more
and realised you really do have to think about your usage cases w
Hmm... that's a tough one. To me, it's a trade off either way, using
a -r parameter to specify the depth for zfs list feels more intuitive
than adding extra commands to modify the -r behaviour, but I can see
your point.
But then, using -c or -d means there's an optional parameter for zfs
list tha
On Fri, Dec 19, 2008 at 6:47 PM, Richard Elling wrote:
> Ross wrote:
>>
>> Well, I really like the idea of an automatic service to manage
>> send/receives to backup devices, so if you guys don't mind, I'm going to
>> share some other ideas for features I think would be useful.
>>
>
> cool.
>
>> On
I was thinking more something like:
- find all disk devices and slices that have ZFS pools on them
- show users the devices and pool names (and UUIDs and device paths in
case of conflicts)..
>>>
>>> I was thinking that device & pool names are too variable, you need
>> Of course, you'll need some settings for this so it's not annoying if
>> people don't want to use it. A simple tick box on that pop up dialog
>> allowing people to say "don't ask me again" would probably do.
>
> I would like something better than that. "Don't ask me again" sucks
> when much, m
On Thu, Dec 18, 2008 at 7:11 PM, Nicolas Williams
wrote:
> On Thu, Dec 18, 2008 at 07:05:44PM +0000, Ross Smith wrote:
>> > Absolutely.
>> >
>> > The tool shouldn't need to know that the backup disk is accessed via
>> > USB, or whateve
> Absolutely.
>
> The tool shouldn't need to know that the backup disk is accessed via
> USB, or whatever. The GUI should, however, present devices
> intelligently, not as cXtYdZ!
Yup, and that's easily achieved by simply prompting for a user
friendly name as devices are attached. Now you could
It sounds to me like there are several potentially valid filesystem
uberblocks available, am I understanding this right?
1. There are four copies of the current uberblock. Any one of these
should be enough to load your pool with no data loss.
2. There are also a few (would love to know how many)
I'm not sure I follow how that can happen, I thought ZFS writes were
designed to be atomic? They either commit properly on disk or they
don't?
On Mon, Dec 15, 2008 at 6:34 PM, Bob Friesenhahn
wrote:
> On Mon, 15 Dec 2008, Ross wrote:
>
>> My concern is that ZFS has all this information on disk,
Forgive me for not understanding the details, but couldn't you also
work backwards through the blocks with ZFS and attempt to recreate the
uberblock?
So if you lost the uberblock, could you (memory and time allowing)
start scanning the disk, looking for orphan blocks that aren't
refernced anywhere
Hi Dan, replying in line:
On Fri, Dec 5, 2008 at 9:19 PM, David Anderson <[EMAIL PROTECTED]> wrote:
> Trying to keep this in the spotlight. Apologies for the lengthy post.
Heh, don't apologise, you should see some of my posts... o_0
> I'd really like to see features as described by Ross in his s
Yeah, thanks Maurice, I just saw that one this afternoon. I guess you
can't reboot with iscsi full stop... o_0
And I've seen the iscsi bug before (I was just too lazy to look it up
lol), I've been complaining about that since February.
In fact it's been a bad week for iscsi here, I've managed to
Hi Richard,
Thanks, I'll give that a try. I think I just had a kernel dump while
trying to boot this system back up though, I don't think it likes it
if the iscsi targets aren't available during boot. Again, that rings
a bell, so I'll go see if that's another known bug.
Changing that setting on
Hey folks,
I've just followed up on this, testing iSCSI with a raided pool, and
it still appears to be struggling when a device goes offline.
>>> I don't see how this could work except for mirrored pools. Would that
>>> carry enough market to be worthwhile?
>>> -- richard
>>>
>>
>> I have to adm
On Fri, Nov 28, 2008 at 5:05 AM, Richard Elling <[EMAIL PROTECTED]> wrote:
> Ross wrote:
>>
>> Well, you're not alone in wanting to use ZFS and iSCSI like that, and in
>> fact my change request suggested that this is exactly one of the things that
>> could be addressed:
>>
>> "The idea is really a
t and
parcel of that.
On Tue, Nov 25, 2008 at 3:57 PM, Bob Friesenhahn
<[EMAIL PROTECTED]> wrote:
> On Tue, 25 Nov 2008, Ross Smith wrote:
>>
>> Good to hear there's work going on to address this.
>>
>> What did you guys think to my idea of ZFS supporting
> The shortcomings of timeouts have been discussed on this list before. How do
> you tell the difference between a drive that is dead and a path that is just
> highly loaded?
A path that is dead is either returning bad data, or isn't returning
anything. A highly loaded path is by definition readi
Hmm, true. The idea doesn't work so well if you have a lot of writes,
so there needs to be some thought as to how you handle that.
Just thinking aloud, could the missing writes be written to the log
file on the rest of the pool? Or temporarily stored somewhere else in
the pool? Would it be an o
No, I count that as "doesn't return data ok", but my post wasn't very
clear at all on that.
Even for a write, the disk will return something to indicate that the
action has completed, so that can also be covered by just those two
scenarios, and right now ZFS can lock the whole pool up if it's
wait
PS. I think this also gives you a chance at making the whole problem
much simpler. Instead of the hard question of "is this faulty",
you're just trying to say "is it working right now?".
In fact, I'm now wondering if the "waiting for a response" flag
wouldn't be better as "possibly faulty". Tha
Hey Jeff,
Good to hear there's work going on to address this.
What did you guys think to my idea of ZFS supporting a "waiting for a
response" status for disks as an interim solution that allows the pool
to continue operation while it's waiting for FMA or the driver to
fault the drive?
I do appre
>> If the file still existed, would this be a case of redirecting the
>> file's top level block (dnode?) to the one from the snapshot? If the
>> file had been deleted, could you just copy that one block?
>>
>> Is it that simple, or is there a level of interaction between files
>> and snapshots tha
> Snapshots are not replacements for traditional backup/restore features.
> If you need the latter, use what is currently available on the market.
> -- richard
I'd actually say snapshots do a better job in some circumstances.
Certainly they're being used that way by the desktop team:
http://blogs.
Hi Darren,
That's storing a dump of a snapshot on external media, but files
within it are not directly accessible. The work Tim et all are doing
is actually putting a live ZFS filesystem on external media and
sending snapshots to it.
A live ZFS filesystem is far more useful (and reliable) than a
No problem. I didn't use mirrored slogs myself, but that's certainly
a step up for reliability.
It's pretty easy to create a boot script to re-create the ramdisk and
re-attach it to the pool too. So long as you use the same device name
for the ramdisk you can add it each time with a simple "zpoo
Oh dear god. Sorry folks, it looks like the new hotmail really doesn't play
well with the list. Trying again in plain text:
> Try to separate the two things:
>
> (1) Try /dev/zero -> mbuffer --- network ---> mbuffer> /dev/null
> That should give you wirespeed
I tried that already. It s
> Try to separate the two things:> > (1) Try /dev/zero -> mbuffer --- network
> ---> mbuffer > /dev/null
> That should give you wirespeed
I tried that already. It still gets just 10-11MB/s from this server.
I can get zfs send / receive and mbuffer working at 30MB/s though from a couple
of test
I'm using 2008-05-07 (latest stable), am I right in assuming that one is ok?
> Date: Wed, 15 Oct 2008 13:52:42 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]; zfs-discuss@opensolaris.org
> Subject: Re: [zfs-discuss] Improving zfs send performance
Thanks, that got it working. I'm still only getting 10MB/s, so it's not solved
my problem - I've still got a bottleneck somewhere, but mbuffer is a huge
improvement over standard zfs send / receive. It makes such a difference when
you can actually see what's going on.
--
Oh cool, that's great news. Thanks Eric.
> Date: Tue, 7 Oct 2008 11:50:08 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: zfs-discuss@opensolaris.org
> Subject: Re: [zfs-discuss] ZFS Mirrors braindead?
>
> On Tue, Oct 07, 2008 at 11:42:57A
Hi Mertol,
Yes, I'm using zfs send -i to just send the changes rather than the whole
thing. I'll have a think about your suggestion for deleting snapshots too,
that does sound like a good idea.
Unfortunately I won't be able to synchronise any applications with this script.
It's backing up
Thinking about it, we could make use of this too. The ability to add a
remote iSCSI mirror to any pool without sacrificing local performance
could be a huge benefit.
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]; zfs-discuss@opensolaris.org
> Subject: Re: Availabilit
EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [zfs-discuss] EMC - top of the table for efficiency, how well
would ZFS do?
CC: zfs-discuss@opensolaris.org
On Sun, Aug 31, 2008 at 10:39 AM, Ross Smith <[EMAIL PROTECTED]> wrote:
Hey Tim,
I'll admit I just quoted the blog w
Hey Tim,
I'll admit I just quoted the blog without checking, I seem to remember the
sales rep I spoke to recommending putting aside 20-50% of my disk for
snapshots. Compared to ZFS where I don't need to reserve any space it feels
very old fashioned. With ZFS, snapshots just take up as much s
Triple mirroring you say? That'd be me then :D
The reason I really want to get ZFS timeouts sorted is that our long term goal
is to mirror that over two servers too, giving us a pool mirrored across two
servers, each of which is actually a zfs iscsi volume hosted on triply mirrored
disks.
Oh
Hi guys,
Bob, my thought was to have this timeout as something that can be optionally
set by the administrator on a per pool basis. I'll admit I was mainly thinking
about reads and hadn't considered the write scenario, but even having thought
about that it's still a feature I'd like. After a
That sounds absolutely perfect Tim, thanks.
Yes, we'll be sending these to other zfs filesystems, although I haven't looked
at the send/receive part of your service yet. What I'd like to do is stage the
send/receive as files on an external disk, and then receive them remotely from
that. I'v
Yup, you got it, and an 8 disk raid-z2 array should still fly for a home system
:D I'm guessing you're on gigabit there? I don't see you having any problems
hitting the bandwidth limit on it.
Ross
> Date: Fri, 22 Aug 2008 11:11:21 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Su
> > Without fail, cfgadm changes the status from "disk" to "sata-port" when I
> > unplug a device attached to port 6 or 7, but most of the time unplugging
> > disks 0-5 results in no change in cfgadm, until I also attach disk 6 or 7.
>
> That does seem inconsistent, or at least, it's not what I'd
Oh god no, I'm already learning three new operating systems, now is not a good
time to add a fourth.
Ross<-- Windows admin now working with Ubuntu, OpenSolaris and ESX
Date: Fri, 15 Aug 2008 10:07:31 -0500From: [EMAIL PROTECTED]: [EMAIL
PROTECTED]: Re: [zfs-discuss] FW: Supermicro AOC-S
Hmm... got a bit more information for you to add to that bug I think.
Zpool import also doesn't work if you have mirrored log devices and either one
of them is offline.
I created two ramdisks with:
# ramdiskadm -a rc-pool-zil-1 256m
# ramdiskadm -a rc-pool-zil-2 256m
And added them to the p
> PROTECTED]> CC: [EMAIL PROTECTED]; zfs-discuss@opensolaris.org> > Ross Smith
> wrote:> > Just a thought, before I go and wipe this zpool, is there any way
> to > > manually recreate the /etc/zfs/zpool.cache file?> > Do you have a copy
> in a snapshot? ZF
Just a thought, before I go and wipe this zpool, is there any way to manually
recreate the /etc/zfs/zpool.cache file?
Ross> Date: Mon, 4 Aug 2008 10:42:43 -0600> From: [EMAIL PROTECTED]> Subject:
Re: [zfs-discuss] Zpool import not working - I broke my pool...> To: [EMAIL
PROTECTED]; [EMAIL PR
Hi Matt,
If it's all 3 disks, I wouldn't have thought it likely to be disk errors, and I
don't think it's a ZFS fault as such. You might be better posting the question
in the storage or help forums to see if anybody there can shed more light on
this.
Ross
> Date: Sun, 3 Aug 2008 16:48:03 +
Sorry Ian, I was posting on the forum and missed the word "disks" from my
previous post. I'm still not used to Sun's mutant cross of a message board /
mailing list.
Ross
> Date: Fri, 1 Aug 2008 21:08:08 +1200> From: [EMAIL PROTECTED]> To: [EMAIL
> PROTECTED]> CC: zfs-discuss@opensolaris.org>
Hey Brent,
On the Sun hardware like the Thumper you do get a nice bright blue "ready to
remove" led as soon as you issue the "cfgadm -c unconfigure xxx" command. On
other hardware it takes a little more care, I'm labelling our drive bays up
*very* carefully to ensure we always remove the rig
Gave up on ZFS ever recovering. A shutdown attempt hung as
expected. I hard-reset the computer.
Ross
> Date: Wed, 30 Jul 2008 11:17:08 -0700> From: [EMAIL PROTECTED]> Subject: Re:
> [zfs-discuss] Supermicro AOC-SAT2-MV8 hang when drive removed> To: [EMAIL
> PROTECTED]&
I agree that device drivers should perform the bulk of the fault monitoring,
however I disagree that this absolves ZFS of any responsibility for checking
for errors. The primary goal of ZFS is to be a filesystem and maintain data
integrity, and that entails both reading and writing data to the
A little more information today. I had a feeling that ZFS would continue quite
some time before giving an error, and today I've shown that you can carry on
working with the filesystem for at least half an hour with the disk removed.
I suspect on a system with little load you could carry on wo
ubject: RE: [zfs-discuss] Supermicro AOC-SAT2-MV8 hang when
> drive removed> > On Mon, 28 Jul 2008, Ross Smith wrote:> > >> > "File
> Browser" is the name of the program that Solaris opens when > > you open
> "Computer" on the desktop. It'
snv_91. I downloaded snv_94 today so I'll be testing with that tomorrow.
> Date: Mon, 28 Jul 2008 09:58:43 -0700> From: [EMAIL PROTECTED]> Subject: Re:
> [zfs-discuss] Supermicro AOC-SAT2-MV8 hang when drive removed> To: [EMAIL
> PROTECTED]> > Which OS and revision?> -- richard> > > Ross wrote:
"File Browser" is the name of the program that Solaris opens when you open
"Computer" on the desktop. It's the default graphical file manager.
It does eventually stop copying with an error, but it takes a good long while
for ZFS to throw up that error, and even when it does, the pool doesn't
It sounds like you might be interested to read up on Eric Schrock's work. I
read today about some of the stuff he's been doing to bring integrated fault
management to Solaris:
http://blogs.sun.com/eschrock/entry/external_storage_enclosures_in_solaris
His last paragraph is great to see, Sun real
bits vs bytes D'oh! again. It's a good job I don't do these calculations
professionally. :-)> Date: Tue, 15 Jul 2008 02:30:33 -0400> From: [EMAIL
PROTECTED]> To: [EMAIL PROTECTED]> Subject: Re: [zfs-discuss] please help with
raid / failure / rebuild calculations> CC: zfs-discuss@opensola
66 matches
Mail list logo
