This problem was fixed in snv_48 last September
and will be
in S10_U4.
U4 doesn't help us any. We need the fix now. :-( By the time U4 is out, we may
even be finished (certainly well on our way) our RAC/ASM migration and this
whole issue will be moot.
Rainer
This message posted from
Thanks for the detailed explanation of the bug. This makes it clearer to us as
to what's happening, and why (which is something I _always_ appreciate!).
Unfortunately, U4 doesn't buy us anything for our current problem.
Rainer
This message posted from opensolaris.org
Rainer,
Have you considered looking for a patch? If you have the supported
version(s) of Solaris (which it sound like you do), this may already be
available in a patch.
Bev.
Rainer Heilke wrote:
Thanks for the detailed explanation of the bug. This makes it clearer to us as
to what's
Sorry, I should have qualified that effective better. I was specifically
speaking in terms of Solaris and price. For companies without a SAN (especially
using Linux), something like a NetApp Filer using UFS is the way to go, I
realize. If you're running Solaris, the cost of QFS becomes a major
Rats, didn't proof accurately. For UFS, I meant NFS.
Rainer
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
The limit is documented as 1 million inodes per TB.
So something
ust not have gone right. But many people have
complained and
you could take the newfs source and fix the
limitation.
Patching the source ourselves would not fly very far, but thanks for the
clarification. I guess I have to
Yes, Anantha is correct that is the bug id, which could be responsible
for more disk writes than expected.
I believe, though, that this would explain at most a factor of 2 of write
expansion (user data getting pushed to disk once in the intent log, then again
in its final location). If the
Anton B. Rang wrote On 01/17/07 20:31,:
Yes, Anantha is correct that is the bug id, which could be responsible
for more disk writes than expected.
I believe, though, that this would explain at most a factor of 2
of write expansion (user data getting pushed to disk once in the
intent log,
