Le 23 oct. 08 à 05:40, Constantin Gonzalez a écrit :
> Hi,
>
> Bob Friesenhahn wrote:
>> On Wed, 22 Oct 2008, Neil Perrin wrote:
>>> On 10/22/08 10:26, Constantin Gonzalez wrote:
3. Disable ZIL[1]. This is of course evil, but one customer
pointed out to me
that if a tar xvf we
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
On Thu, 23 Oct 2008, Constantin Gonzalez wrote:
>
> This is what the customer told me. He uses rsync and he is ok with restarting
> the rsync whenever the NFS server restarts.
Then remind your customer to tell rsync to inspect the data rather
than trusting time stamps. Rsync will then run quite
Hi,
Bob Friesenhahn wrote:
> On Thu, 23 Oct 2008, Constantin Gonzalez wrote:
>>
>> Yes, we're both aware of this. In this particular situation, the customer
>> would restart his backup job (and thus the client application) in case
>> the
>> server dies.
>
> So it is ok for this customer if their
On Thu, 23 Oct 2008, Constantin Gonzalez wrote:
>
> Yes, we're both aware of this. In this particular situation, the customer
> would restart his backup job (and thus the client application) in case the
> server dies.
So it is ok for this customer if their backup becomes silently
corrupted and th
Hi,
yes, using slogs is the best solution.
Meanwhile, using mirrored slogs from other servers' RAM-Disks running on UPSs
seem like an interesting idea, if the reliability of UPS-backed RAM is deemed
reliable enough for the purposes of the NFS server.
Thanks for siggesting this!
Cheers,
Cons
Hi,
Bob Friesenhahn wrote:
> On Wed, 22 Oct 2008, Neil Perrin wrote:
>> On 10/22/08 10:26, Constantin Gonzalez wrote:
>>> 3. Disable ZIL[1]. This is of course evil, but one customer pointed out to
>>> me
>>> that if a tar xvf were writing locally to a ZFS file system, the writes
>>> would
Hi,
>> - The ZIL exists on a per filesystem basis in ZFS. Is there an RFE
>> already
>>that asks for the ability to disable the ZIL on a per filesystem
>> basis?
>
> Yes: 6280630 zil synchronicity
good, thanks for the pointer!
> Though personally I've been unhappy with the exposure that z
Ricardo M. Correia wrote:
> Hi Richard,
>
> On Qua, 2008-10-22 at 14:04 -0700, Richard Elling wrote:
>
>> It is more important to use a separate disk, than to use a separate and fast
>> disk. Anecdotal evidence suggests that using a USB hard disk works
>> well.
>>
>
> While I don't necessa
Hi Richard,
On Qua, 2008-10-22 at 14:04 -0700, Richard Elling wrote:
> It is more important to use a separate disk, than to use a separate and fast
> disk. Anecdotal evidence suggests that using a USB hard disk works
> well.
While I don't necessarily disagree with your statement, please note tha
On Wed, Oct 22, 2008 at 04:46:00PM -0400, Miles Nordin wrote:
> I thought NFSv2 -> NFSv3 was supposed to make this prestoserv, SSD,
> battery-backed DRAM stuff not needed for good performance any more. I
> guess not though.
There are still a number of operations in NFSv3 and NFSv4 which the
clien
Constantin Gonzalez wrote:
> Hi,
>
> On a busy NFS server, performance tends to be very modest for large amounts
> of small files due to the well known effects of ZFS and ZIL honoring the
> NFS COMMIT operation[1].
>
> For the mature sysadmin who knows what (s)he does, there are three
> possibiliti
On Wed, 22 Oct 2008, Miles Nordin wrote:
>
> I thought NFSv2 -> NFSv3 was supposed to make this prestoserv, SSD,
> battery-backed DRAM stuff not needed for good performance any more. I
> guess not though.
The intent was to allow the server to be able to buffer up more
uncommitted data before the
> "cg" == Constantin Gonzalez <[EMAIL PROTECTED]> writes:
cg> if a tar xvf were writing locally to a ZFS file system, the
cg> writes wouldn't be synchronous either, so there's no point in
cg> forcing NFS users to having a better
It's worse for NFS because breaking the commit/lease
On 10/22/08 13:56, Marcelo Leal wrote:
>>> But the slog is the ZIL. formaly a *separate*
>> intent log.
>>
>> No the slog is not the ZIL!
> Ok, when you did write this:
> "I've been slogging for a while on support for separate intent logs (slogs)
> for ZFS.
> Without slogs, the ZIL is allocated
> > But the slog is the ZIL. formaly a *separate*
> intent log.
>
> No the slog is not the ZIL!
Ok, when you did write this:
"I've been slogging for a while on support for separate intent logs (slogs)
for ZFS. Without slogs, the ZIL is allocated dynamically from the main pool".
You were talki
> But the slog is the ZIL. formaly a *separate* intent log.
No the slog is not the ZIL!
Here's the definition of the terms as we've been trying to use them:
ZIL:
The body of code the supports synchronous requests, which writes
out to the Intent Logs
Intent Log:
A stable s
On Wed, 2008-10-22 at 10:45 -0600, Neil Perrin wrote:
> Yes: 6280630 zil synchronicity
>
> Though personally I've been unhappy with the exposure that zil_disable has
> got.
> It was originally meant for debug purposes only. So providing an official
> way to make synchronous behaviour asynchronous
> Bah, I've done it again. I meant use it as a slog
> device, not as the ZIL...
But the slog is the ZIL. formaly a *separate* intent log. What´s the matter? I
think everyone did understand. I think you did make a confusion some threads
before about ZIL and L2ARC. That is a different thing.. ;-)
Bah, I've done it again. I meant use it as a slog device, not as the ZIL...
I'll get this terminology in my head eventually.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org
Well, it might be even more of a bodge than disabling the ZIL, but how about:
- Create a 512MB ramdisk, use that for the ZIL
- Buy a Micro Memory nvram PCI card for £100 or so.
- Wait 3-6 months, hopefully buy a fully supported PCI-e SSD to replace the
Micro Memory card.
The ramdisk isn't an ide
I agree with you Constantin that the sync is a performance problem, in the same
way i think in a NFS environment it is just *required*. If the sync can be
relaxed in a "specific NFS environment", my first opinion is that the NFS is
not necessary on that environment in first place.
IMHO a proto
On Wed, 22 Oct 2008, Neil Perrin wrote:
>
> On 10/22/08 10:26, Constantin Gonzalez wrote:
>> 3. Disable ZIL[1]. This is of course evil, but one customer pointed out to me
>> that if a tar xvf were writing locally to a ZFS file system, the writes
>> wouldn't be synchronous either, so there's
On 10/22/08 10:26, Constantin Gonzalez wrote:
> Hi,
>
> On a busy NFS server, performance tends to be very modest for large amounts
> of small files due to the well known effects of ZFS and ZIL honoring the
> NFS COMMIT operation[1].
>
> For the mature sysadmin who knows what (s)he does, there
Hi,
On a busy NFS server, performance tends to be very modest for large amounts
of small files due to the well known effects of ZFS and ZIL honoring the
NFS COMMIT operation[1].
For the mature sysadmin who knows what (s)he does, there are three
possibilities:
1. Live with it. Hard, if you see 10
25 matches
Mail list logo
