On 16/02/2010 21:54, Jeff Bonwick wrote:
People used fastfs for years in specific environments (hopefully
understanding the risks), and disabling the ZIL is safer than fastfs.
Seems like it would be a useful ZFS dataset parameter.
We agree. There's an open RFE for this:
6280630 zil
On May 4, 2010, at 2:02 PM, Robert Milkowski wrote:
On 16/02/2010 21:54, Jeff Bonwick wrote:
People used fastfs for years in specific environments (hopefully
understanding the risks), and disabling the ZIL is safer than fastfs.
Seems like it would be a useful ZFS dataset parameter.
We
On 17/02/2010 09:55, Robert Milkowski wrote:
On 16/02/2010 23:59, Christo Kutrovsky wrote:
On ZVOLs it appears the setting kicks in life. I've tested this by
turning it off/on and testing with iometer on an exported iSCSI
device (iscsitgtd not comstar).
I haven't looked at zvol's code
On 25/02/2010 12:48, Robert Milkowski wrote:
On 17/02/2010 09:55, Robert Milkowski wrote:
On 16/02/2010 23:59, Christo Kutrovsky wrote:
On ZVOLs it appears the setting kicks in life. I've tested this by
turning it off/on and testing with iometer on an exported iSCSI
device (iscsitgtd not
On 16/02/2010 23:59, Christo Kutrovsky wrote:
Robert,
That would be pretty cool especially if it makes into the 2010.02 release. I
hope there are no weird special cases that pop-up from this improvement.
I'm pretty sure it won't make 2010.03
Regarding workaround.
That's not my
Eric, is this answer by George wrong?
http://opensolaris.org/jive/message.jspa?messageID=439187#439187
Are we to expect the fix soon or is there still no schedule?
Thanks,
Moshe
--
This message posted from opensolaris.org
___
zfs-discuss mailing
Darren J Moffat wrote:
You have done a risk analysis and if you are happy that your NTFS
filesystems could be corrupt on those ZFS ZVOLs if you lose data then
you could consider turning off the ZIL. Note though that it isn't
just those ZVOLs you are serving to Windows that lose access to a
People used fastfs for years in specific environments (hopefully
understanding the risks), and disabling the ZIL is safer than fastfs.
Seems like it would be a useful ZFS dataset parameter.
We agree. There's an open RFE for this:
6280630 zil synchronicity
No promise on date, but it will
Jeff, thanks for link, looking forward to per data set control.
6280630 zil synchronicity
(http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6280630)
It's been open for 5 years now :) Looking forward to not compromising my entire
storage with disabled ZIL when I only need it on a few
On Tue, Feb 16, 2010 at 02:53:18PM -0800, Christo Kutrovsky wrote:
looking to answer myself the following question:
Do I need to rollback all my NTFS volumes on iSCSI to the last available
snapshot every time there's a power failure involving the ZFS storage server
with a disabled ZIL.
No,
On 16/02/2010 22:53, Christo Kutrovsky wrote:
Jeff, thanks for link, looking forward to per data set control.
6280630 zil synchronicity
(http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6280630)
It's been open for 5 years now :) Looking forward to not compromising my entire
storage
Ok, now that you explained it, it makes sense. Thanks for replying Daniel.
Feel better now :) Suddenly, that Gigabyte i-Ram is no longer a necessity but a
nice to have thing.
What would be really good to have is the that per-data set ZIL control in
2010.02. And perhaps add another mode sync no
Robert,
That would be pretty cool especially if it makes into the 2010.02 release. I
hope there are no weird special cases that pop-up from this improvement.
Regarding workaround.
That's not my experience, unless it behaves differently on ZVOLs and datasets.
On ZVOLs it appears the setting
I have a similar situation. I have a system that is used for backup copies of
logs and other non-critical things, where the primary copy is on a Netapp. Data
gets written in batches a few times a day. We use this system because storage
on it is a lot less expensive than on the Netapp. It's only
ck == Christo Kutrovsky kutrov...@pythian.com writes:
djm == Darren J Moffat darr...@opensolaris.org writes:
kth == Kjetil Torgrim Homme kjeti...@linpro.no writes:
ck The never turn off the ZIL sounds scary, but if the only
ck consequences are 15 (even 45) seconds of data loss .. i am
On Feb 6, 2010, at 11:30 PM, Christo Kutrovsky wrote:
Eric, thanks for clarifying.
Could you confirm the release for #1 ? As today can be misleading depending
on the user.
A long time (snv_96/s10u8).
Is there a schedule/target for #2 ?
No.
And just to confirm the alternative to turn
Eric,
I am confused. What's difference between:
- turning off slogs (via logbias)
vs
- turning off ZIL (via kernel tunable)
Isn't that similar, just one is more granular?
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
Darren, thanks for reply.
Still not clear to me thought.
The only purpose of the slog is to serve the ZIL. There may be many ZILs on a
single slog.
From Milek's blog:
logbias=latency - data written to slog first
logbias=throughtput - data written directly to dataset.
Here's my problem. I
On 07/02/2010 20:56, Christo Kutrovsky wrote:
Darren, thanks for reply.
Still not clear to me thought.
Based on what you wrote below you do understand it.
The only purpose of the slog is to serve the ZIL. There may be many ZILs on a
single slog.
Correct, and correct.
From Milek's
Has anyone seen soft corruption in NTFS iSCSI ZVOLs after a power loss?
I mean, there is no guarantee writes will be executed in order, so in theory,
one could corrupt it's NTFS file system.
Would best practice be to rollback the last snapshot before making those iSCSI
available again?
--
Christo Kutrovsky kutrov...@pythian.com writes:
Has anyone seen soft corruption in NTFS iSCSI ZVOLs after a power
loss?
this is not from experience, but I'll answer anyway.
I mean, there is no guarantee writes will be executed in order, so in
theory, one could corrupt it's NTFS file system.
Me too, I would like to know the answer.
I am considering Gigabyte's i-RAM for ZIL, but I don't want to worry what
happens if the battery dies after a system crash.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
On Feb 6, 2010, at 10:18 PM, Christo Kutrovsky wrote:
Me too, I would like to know the answer.
I am considering Gigabyte's i-RAM for ZIL, but I don't want to worry what
happens if the battery dies after a system crash.
There are two different things here:
1. Opening a pool with a
Eric, thanks for clarifying.
Could you confirm the release for #1 ? As today can be misleading depending
on the user.
Is there a schedule/target for #2 ?
And just to confirm the alternative to turn off the ZIL globally is the
equivalent to always throwing away some commited data on a
Hello list,
someone (actually neil perrin (CC)) mentioned in this thread:
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-December/034340.html
that is should be possible to import a pool with failed log devices
(with or without data loss ?).
/
// Has the following error no
25 matches
Mail list logo
