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 were writing locally
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 zil_disable
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
wouldn't be
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,
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 the
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 backup
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 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
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
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 are
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 no
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
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
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.. ;-)
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 is
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
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 talking
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 dynamically
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/batch
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
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
possibilities:
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
client
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 that
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 necessarily disagree
24 matches
Mail list logo
