up to the next recordsize
boundary, are we guaranteed to be able to get the from the blocksize
reported by statvfs?
--
Andrew Deason
adea...@sinenomine.net
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Mon, 21 Sep 2009 18:20:53 -0400
Richard Elling wrote:
> On Sep 21, 2009, at 2:43 PM, Andrew Deason wrote:
>
> > On Mon, 21 Sep 2009 17:13:26 -0400
> > Richard Elling wrote:
> >
> >> You don't know the max overhead for the file before it is
> >>
this, it seems like the worst case is when copies=3.
Is that max with copies=3? Assume copies=1; what is it then?
--
Andrew Deason
adea...@sinenomine.net
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
t commit delay.
But solving the general problem for me isn't necessary. If I could just
get a ballpark estimate of the max overhead for a file, I would be fine.
I haven't payed attention to it before, so I don't even have an
intuitive feel for what it is.
--
Andrew Deason
adea...
nly possible for other applications to fill up the disk. We
just need to ensure that we don't fill up the disk to block other
applications. You may think this is fruitless, and just from that
description alone, it may be. But you must understand that with
efficiency somewhat. Files are truncated to 0 and grow again quite often
in busy clients. But that's an efficiency issue, we'd still be able to
stay within the configured limit that way.
But anyway, 128k may be fine for me, but what about if someone sets
thei
er of filesystem-specific steps needed to be taken to set up the
cache. You don't need to do anything special for a tmpfs cache, for
instance, or ext2/3 caches on linux.
--
Andrew Deason
adea...@sinenomine.net
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
pothetical case of the metadata compression ratio being
effectively the same as without compression, what would it be then?
--
Andrew Deason
adea...@sinenomine.net
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
the space calculations to be made /before/ the
write is done. It may be possible to change that, but I'd rather not, if
possible (and I'd have to make sure there's not a significant speed hit
in doing so).
--
Andrew Deason
adea...@sinenomine.net
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
and any additional parameters needed).
If we just have a way of knowing in advance how much disk space we're
going to take up by writing a certain amount of data, we should be
okay.
Or, if anyone has any other ideas on how to overcome this, it would be
welcomed.
--
Andrew Deason
adea...@s
10 matches
Mail list logo
