On Wed, Jul 31 2013 at 5:53pm -0400,
Chris Murphy li...@colorremedies.com wrote:
On Jul 31, 2013, at 12:38 PM, Eric Sandeen sand...@redhat.com wrote:
i.e. if you only want the efficient snapshots, a way to fully-provision
a thinp device. I'm still not sure if this is possible…?
Am 31.07.2013 21:24, schrieb Matthew Miller:
On Wed, Jul 31, 2013 at 08:18:52PM +0200, Reindl Harald wrote:
you are aware how much 10% of 8 TB are?
So why *not* keep more logs, at least while nothing else is using it?
to save space?
there where i use Thin Provisioning are full backups of
On 07/29/2013 08:38 PM, Ric Wheeler wrote:
If application A does a stat or statvfs() call, sees 1GB of space left
and then does a write, we could easily lose that race to any other
application.
If you want to reserve space, you need to grab the space yourself
(always works with a large write()
Dne 31.7.2013 10:39, Florian Weimer napsal(a):
On 07/29/2013 08:38 PM, Ric Wheeler wrote:
If application A does a stat or statvfs() call, sees 1GB of space left
and then does a write, we could easily lose that race to any other
application.
If you want to reserve space, you need to grab the
On Mon, Jul 29 2013 at 2:49pm -0400,
Daniel P. Berrange berrangeatredhat.com wrote:
On Mon, Jul 29, 2013 at 02:38:23PM -0400, Ric Wheeler wrote:
On 07/29/2013 10:18 AM, Daniel P. Berrange wrote:
On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote:
On Jul 29, 2013, at 6:30 AM,
On Mon, Jul 29 2013 at 2:48pm -0400,
Eric Sandeen sandeenatredhat.com wrote:
On 7/27/13 11:56 AM, Lennart Poettering wrote:
On Fri, 26.07.13 22:13, Miloslav Trmač (mitr at volny.cz) wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a
On Wed, Jul 31 2013 at 5:52am -0400,
Zdenek Kabelac zkabe...@redhat.com wrote:
Dne 31.7.2013 10:39, Florian Weimer napsal(a):
On 07/29/2013 08:38 PM, Ric Wheeler wrote:
If application A does a stat or statvfs() call, sees 1GB of space left
and then does a write, we could easily lose that
On 07/31/2013 10:32 AM, Mike Snitzer wrote:
On Mon, Jul 29 2013 at 2:48pm -0400,
Eric Sandeen sandeenatredhat.com wrote:
On 7/27/13 11:56 AM, Lennart Poettering wrote:
On Fri, 26.07.13 22:13, Miloslav Trmač (mitr at volny.cz) wrote:
Hello all,
with thin provisioning available, the total
On Jul 31, 2013, at 8:32 AM, Mike Snitzer snit...@redhat.com wrote:
But on the desktop the fedora
developers need to provide sane policy/defaults.
Right. And the concern I have (other than a blatant bug), is the F20 feature
for the installer to create thinp LVs; and to do that the installer
On Mon, Jul 29, 2013 at 05:34:05PM -0400, Simo Sorce wrote:
On Mon, 2013-07-29 at 23:06 +0200, Lennart Poettering wrote:
Well, the point I am making is that it is wrong to ask userspace to
handle this. Get the APIs right you expose to userspace.
If user space assume it can use 'all the
On 7/31/13 12:08 PM, Chris Murphy wrote:
On Jul 31, 2013, at 8:32 AM, Mike Snitzer snit...@redhat.com
wrote:
But on the desktop the fedora developers need to provide sane
policy/defaults.
Right. And the concern I have (other than a blatant bug), is the F20
feature for the installer to
Am 31.07.2013 20:14, schrieb Zbigniew Jędrzejewski-Szmek:
journald provides configuration knobs to exactly set the limits.
But forcing the admin to always configure this is something that
should be avoided, and reasonable values that work OK most of the
time should be used. Those defaults
On Wed, Jul 31, 2013 at 08:18:52PM +0200, Reindl Harald wrote:
you are aware how much 10% of 8 TB are?
So why *not* keep more logs, at least while nothing else is using it?
you need at least a lot of more fuzzy logic
* not more than XXX MB
* or vary the percentage depending on the drive size
On Wed, Jul 31 2013 at 1:08pm -0400,
Chris Murphy li...@colorremedies.com wrote:
On Jul 31, 2013, at 8:32 AM, Mike Snitzer snit...@redhat.com wrote:
But on the desktop the fedora
developers need to provide sane policy/defaults.
Right. And the concern I have (other than a blatant
On Wed, Jul 31 2013 at 2:38pm -0400,
Eric Sandeen sand...@redhat.com wrote:
On 7/31/13 12:08 PM, Chris Murphy wrote:
On Jul 31, 2013, at 8:32 AM, Mike Snitzer snit...@redhat.com
wrote:
But on the desktop the fedora developers need to provide sane
policy/defaults.
Right. And
On Jul 31, 2013, at 1:44 PM, Mike Snitzer snit...@redhat.com wrote:
Did you ever look
to see if CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is enabled?
It's not enabled in either the regular or debug kernels found in koji.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, 2013-07-31 at 11:52 +0200, Zdenek Kabelac wrote:
...
ThinP should be configured in a way that admin is able to extend pool to
honour promised space if really needed. It's not a good idea, to provision
1EB
if you have at most just 1TB disk and then you expect you will have no
On Wed, 2013-07-31 at 13:38 -0500, Eric Sandeen wrote:
On 7/31/13 12:08 PM, Chris Murphy wrote:
On Jul 31, 2013, at 8:32 AM, Mike Snitzer snit...@redhat.com
wrote:
But on the desktop the fedora developers need to provide sane
policy/defaults.
Right. And the concern I have
On Jul 31, 2013, at 12:38 PM, Eric Sandeen sand...@redhat.com wrote:
i.e. if you only want the efficient snapshots, a way to fully-provision
a thinp device. I'm still not sure if this is possible…?
[…]
I guess I'm pretty nervous about offering actual thin provisioned
storage to
Dne 29.7.2013 23:06, Lennart Poettering napsal(a):
On Mon, 29.07.13 16:52, Ric Wheeler (rwhee...@redhat.com) wrote:
Oh, we don't assume it's all ours. We recheck regularly, immediately
before appending to the journal files, of course assuming that we are
not the only writers.
With thinly
On Sat, Jul 27, 2013 at 6:56 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Fri, 26.07.13 22:13, Miloslav Trmač (m...@volny.cz) wrote:
The same applies if your package automatically allocates a certain
proportion of the total or available space.
A quick way to check whether your
On Fri, Jul 26, 2013 at 10:06:20PM +0100, Richard W.M. Jones wrote:
On Fri, Jul 26, 2013 at 10:13:42PM +0200, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is
On Jul 29, 2013, at 6:30 AM, Daniel P. Berrange berra...@redhat.com wrote:
Yep, we need to be able to report free space on filesystems, so that
apps provisioning virtual machines can get an idea of how much storage
they can provide to VMs without risk of over comitting.
I agree that we
On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote:
On Jul 29, 2013, at 6:30 AM, Daniel P. Berrange berra...@redhat.com wrote:
Yep, we need to be able to report free space on filesystems, so that
apps provisioning virtual machines can get an idea of how much storage
they can
On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote:
On Jul 29, 2013, at 6:30 AM, Daniel P. Berrange berra...@redhat.com wrote:
Yep, we need to be able to report free space on filesystems, so that
apps provisioning virtual machines can get an idea of how much storage
they can
On Jul 29, 2013, at 8:18 AM, Daniel P. Berrange berra...@redhat.com wrote:
From an API POV, libvirt doesn't need/care about the free space on the
volume underlying the filesystem. We actually only care about the free
space in a given directory that we're using for disk images. It just
On 07/29/2013 10:01 AM, Chris Murphy wrote:
On Jul 29, 2013, at 6:30 AM, Daniel P. Berrange berra...@redhat.com wrote:
Yep, we need to be able to report free space on filesystems, so that
apps provisioning virtual machines can get an idea of how much storage
they can provide to VMs without
On 07/29/2013 10:18 AM, Daniel P. Berrange wrote:
On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote:
On Jul 29, 2013, at 6:30 AM, Daniel P. Berrange berra...@redhat.com wrote:
Yep, we need to be able to report free space on filesystems, so that
apps provisioning virtual machines
On 7/27/13 11:56 AM, Lennart Poettering wrote:
On Fri, 26.07.13 22:13, Miloslav Trmač (m...@volny.cz) wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the actual
On Mon, Jul 29, 2013 at 02:38:23PM -0400, Ric Wheeler wrote:
On 07/29/2013 10:18 AM, Daniel P. Berrange wrote:
On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote:
On Jul 29, 2013, at 6:30 AM, Daniel P. Berrange berra...@redhat.com
wrote:
Yep, we need to be able to report free
On Friday, July 26, 2013 09:29:41 PM Eric Sandeen wrote:
On 7/26/13 3:13 PM, Miloslav Trmač wrote:
A quick way to check whether your package is likely to be affected, is
to look for statfs() or statvfs() calls in C, or the equivalent in
your higher-level library / programming language.
On 07/29/2013 03:05 PM, Steve Grubb wrote:
On Friday, July 26, 2013 09:29:41 PM Eric Sandeen wrote:
On 7/26/13 3:13 PM, Miloslav Trmač wrote:
A quick way to check whether your package is likely to be affected, is
to look for statfs() or statvfs() calls in C, or the equivalent in
your
On Jul 29, 2013, at 1:05 PM, Steve Grubb sgr...@redhat.com wrote:
The audit system also cares about space available. We tell people to create a
partition specifically for auditing so that we can keep close track on what's
left.
How does the audit system determine space available? If it's
Once upon a time, Chris Murphy li...@colorremedies.com said:
How does the audit system determine space available? If it's using btrfs
configured for raid1 or raid10, df and stat will report the total storage of
all devices in the volume, unlike md raid (or even proprietary raid). Instead
df
On 07/29/2013 03:50 PM, Chris Adams wrote:
Once upon a time, Chris Murphy li...@colorremedies.com said:
How does the audit system determine space available? If it's using btrfs
configured for raid1 or raid10, df and stat will report the total storage of
all devices in the volume, unlike md
On Mon, 29.07.13 13:48, Eric Sandeen (sand...@redhat.com) wrote:
Well, I am pretty sure the burden must be on the file systems to report
a useful estimate free blocks value in statfs()/statvfs(). Exporting that
problem to userspace and expecting userspace to work around this is just
On Monday, July 29, 2013 01:41:12 PM Chris Murphy wrote:
On Jul 29, 2013, at 1:05 PM, Steve Grubb sgr...@redhat.com wrote:
The audit system also cares about space available. We tell people to
create a partition specifically for auditing so that we can keep close
track on what's left.
How
On 07/29/2013 04:35 PM, Lennart Poettering wrote:
On Mon, 29.07.13 13:48, Eric Sandeen (sand...@redhat.com) wrote:
Well, I am pretty sure the burden must be on the file systems to report
a useful estimate free blocks value in statfs()/statvfs(). Exporting that
problem to userspace and
On Mon, 29.07.13 16:52, Ric Wheeler (rwhee...@redhat.com) wrote:
Oh, we don't assume it's all ours. We recheck regularly, immediately
before appending to the journal files, of course assuming that we are
not the only writers.
With thinly provisioned storage (or things like btrfs, writeable
On Mon, 2013-07-29 at 23:06 +0200, Lennart Poettering wrote:
Well, the point I am making is that it is wrong to ask userspace to
handle this. Get the APIs right you expose to userspace.
If user space assume it can use 'all the space up to 15% from exhausting
space' then it is user space that
On 07/29/2013 05:06 PM, Lennart Poettering wrote:
On Mon, 29.07.13 16:52, Ric Wheeler (rwhee...@redhat.com) wrote:
Oh, we don't assume it's all ours. We recheck regularly, immediately
before appending to the journal files, of course assuming that we are
not the only writers.
With thinly
On Jul 29, 2013, at 3:34 PM, Simo Sorce s...@redhat.com wrote:
btrfs consumes space on each write to the same block.
If you have a 10GB file system with a 5GB, existing log file and overwrite it
twice in place, you will run out of space.
It's a sufficiently confusing example, that I
On Jul 29, 2013, at 3:06 PM, Lennart Poettering mzerq...@0pointer.de wrote:
Well, journald is totally fine if it is lied to in the sense that the
values returned by statfs()/statvfs() are just estimates, and not
precise. However, it is assumed that the values are not off by 100% as
they
On 27.07.2013 05:07, Chris Murphy wrote:
On Jul 26, 2013, at 4:53 PM, Pádraig Brady p...@draigbrady.com wrote:
On 07/26/2013 09:13 PM, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that
On Fri, 26.07.13 22:13, Miloslav Trmač (m...@volny.cz) wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the actual backing storage may be smaller, or
shared with
On Fri, 26.07.13 21:29, Eric Sandeen (sand...@redhat.com) wrote:
On 7/26/13 3:13 PM, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the
On Sat, Jul 27, 2013 at 07:02:41PM +0200, Lennart Poettering wrote:
On Fri, 26.07.13 21:29, Eric Sandeen (sand...@redhat.com) wrote:
On 7/26/13 3:13 PM, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not
On Sat, Jul 27, 2013 at 06:25:57PM +0100, Richard W.M. Jones wrote:
I also appreciate this will not be easy with the sheer variety of
underlying storage. Also the problem is not well-defined: What
happens if the underlying storage is storing two guests, and either of
them could grow to the
On Jul 27, 2013, at 10:56 AM, Lennart Poettering mzerq...@0pointer.de wrote:
Well, I am pretty sure the burden must be on the file systems to report
a useful estimate free blocks value in statfs()/statvfs().
tl;dr
4 VMs, each using one thinp LV. Each LV has a virtualsize of 1TB. The VG
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the actual backing storage may be smaller, or
shared with other filesystems).
If your package reports disk space usage to
If your package reports disk space usage to users, and bases this on
filesystem free space, please consider whether it might need to take
LVM thin provisioning into account.
Perhaps you could include a small code snippet explaining *how* to do
this? Is there an lvm_thin_statfs() we can use?
On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie d...@redhat.com wrote:
If your package reports disk space usage to users, and bases this on
filesystem free space, please consider whether it might need to take
LVM thin provisioning into account.
Perhaps you could include a small code snippet
On Fri, Jul 26, 2013 at 10:59 PM, Miloslav Trmač m...@volny.cz wrote:
On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie d...@redhat.com wrote:
If your package reports disk space usage to users, and bases this on
filesystem free space, please consider whether it might need to take
LVM thin
On Fri, Jul 26, 2013 at 10:13:42PM +0200, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the actual backing storage may be smaller, or
shared with
On Fri, Jul 26, 2013 at 10:13:42PM +0200, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the actual backing storage may be smaller, or
shared with
On Jul 26, 2013, at 3:02 PM, drago01 drag...@gmail.com wrote:
On Fri, Jul 26, 2013 at 10:59 PM, Miloslav Trmač m...@volny.cz wrote:
On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie d...@redhat.com wrote:
If your package reports disk space usage to users, and bases this on
filesystem free
On Fri, 2013-07-26 at 22:59 +0200, Miloslav Trmač wrote:
On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie d...@redhat.com wrote:
If your package reports disk space usage to users, and bases this on
filesystem free space, please consider whether it might need to take
LVM thin provisioning into
On Jul 26, 2013, at 3:34 PM, David Lehman dleh...@redhat.com wrote:
On Fri, 2013-07-26 at 22:59 +0200, Miloslav Trmač wrote:
On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie d...@redhat.com wrote:
If your package reports disk space usage to users, and bases this on
filesystem free space,
On 07/26/2013 09:13 PM, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the actual backing storage may be smaller, or
shared with other
On 7/26/13 3:13 PM, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the actual backing storage may be smaller, or
shared with other filesystems).
On Jul 26, 2013, at 4:53 PM, Pádraig Brady p...@draigbrady.com wrote:
On 07/26/2013 09:13 PM, Miloslav Trmač wrote:
Hello all,
with thin provisioning available, the total and free space values
reported by a filesystem do not necessarily mean that that much space
is _actually_ available (the
61 matches
Mail list logo
