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 backu
On Wed, Jul 31 2013 at 5:53pm -0400,
Chris Murphy wrote:
>
> On Jul 31, 2013, at 12:38 PM, Eric Sandeen 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 pr
On Jul 31, 2013, at 12:38 PM, Eric Sandeen 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 "average" Fedora
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
> > wrote:
> >
> >> But on the desktop the fedora developers need to provide sane
> >> policy/defaults.
> >
> > Right. And the concern I have (othe
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
> p
On Jul 31, 2013, at 1:44 PM, Mike Snitzer 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
https://admin.fedoraproject
On Wed, Jul 31 2013 at 2:38pm -0400,
Eric Sandeen wrote:
> On 7/31/13 12:08 PM, Chris Murphy wrote:
> >
> > On Jul 31, 2013, at 8:32 AM, Mike Snitzer
> > wrote:
> >
> >> But on the desktop the fedora developers need to provide sane
> >> policy/defaults.
> >
> > Right. And the concern I have
On Wed, Jul 31 2013 at 1:08pm -0400,
Chris Murphy wrote:
>
> On Jul 31, 2013, at 8:32 AM, Mike Snitzer 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 in
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 s
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 7/31/13 12:08 PM, Chris Murphy wrote:
>
> On Jul 31, 2013, at 8:32 AM, Mike Snitzer
> 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 t
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
On Jul 31, 2013, at 8:32 AM, Mike Snitzer 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 needs to
know wh
On 07/31/2013 10:32 AM, Mike Snitzer wrote:
On Mon, Jul 29 2013 at 2:48pm -0400,
Eric Sandeen 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
On Wed, Jul 31 2013 at 5:52am -0400,
Zdenek Kabelac 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 race to an
On Mon, Jul 29 2013 at 2:48pm -0400,
Eric Sandeen 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 filesystem
On Mon, Jul 29 2013 at 2:49pm -0400,
Daniel P. Berrange 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, "Daniel P. Ber
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 sp
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 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 prov
On Jul 29, 2013, at 3:06 PM, Lennart Poettering 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 might be on thinp
On Jul 29, 2013, at 3:34 PM, Simo Sorce 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 almost wish df
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 provis
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 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, wri
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 expecting
On Monday, July 29, 2013 01:41:12 PM Chris Murphy wrote:
> On Jul 29, 2013, at 1:05 PM, Steve Grubb 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
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 07/29/2013 03:50 PM, Chris Adams wrote:
Once upon a time, Chris Murphy 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
Once upon a time, Chris Murphy 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 reports logs files
On Jul 29, 2013, at 1:05 PM, Steve Grubb 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 using btrfs
c
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 higher-lev
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 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"
> >>wrote:
> >>
> >>>Yep, we need to be able to report free space
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 (t
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" wrote:
Yep, we need to be able to report free space on filesystems, so that
apps provisioning virtual machines can get an idea of h
On 07/29/2013 10:01 AM, Chris Murphy wrote:
On Jul 29, 2013, at 6:30 AM, "Daniel P. Berrange" 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 comittin
On Jul 29, 2013, at 8:18 AM, Daniel P. Berrange 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
> happens that we impl
On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote:
>
> On Jul 29, 2013, at 6:30 AM, "Daniel P. Berrange" 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
On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote:
>
> On Jul 29, 2013, at 6:30 AM, "Daniel P. Berrange" 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
On Jul 29, 2013, at 6:30 AM, "Daniel P. Berrange" 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 really want the
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 Sat, Jul 27, 2013 at 6:56 PM, Lennart Poettering
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 package is likely
On 27.07.2013 05:07, Chris Murphy wrote:
On Jul 26, 2013, at 4:53 PM, Pádraig Brady 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 _actu
On Jul 27, 2013, at 10:56 AM, Lennart Poettering 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
backing those LVs is
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 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 filesyste
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 (t
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 w
On Jul 26, 2013, at 4:53 PM, Pádraig Brady 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 actual bac
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 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 filesys
On Jul 26, 2013, at 3:34 PM, David Lehman wrote:
> On Fri, 2013-07-26 at 22:59 +0200, Miloslav Trmač wrote:
>> On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie wrote:
>>>
If your package reports disk space usage to users, and bases this on
filesystem free space, please consider whether i
On Fri, 2013-07-26 at 22:59 +0200, Miloslav Trmač wrote:
> On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie 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 acc
On Jul 26, 2013, at 3:02 PM, drago01 wrote:
> On Fri, Jul 26, 2013 at 10:59 PM, Miloslav Trmač wrote:
>> On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie wrote:
>>>
If your package reports disk space usage to users, and bases this on
filesystem free space, please consider whether it mig
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
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
On Fri, Jul 26, 2013 at 10:59 PM, Miloslav Trmač wrote:
> On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie 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
On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie 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 explaining
> 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
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 user
On Jul 17, 2013, at 3:23 PM, Adam Williamson wrote:
> On Wed, 2013-07-17 at 15:20 -0600, Chris Murphy wrote:
>> On Jul 17, 2013, at 2:59 PM, Colin Walters wrote:
>>
>>> On Wed, 2013-07-17 at 13:36 -0700, Adam Williamson wrote:
>>>
Does 'new automatic partitioning variant' mean 'ano
On Wed, 2013-07-17 at 15:20 -0600, Chris Murphy wrote:
> On Jul 17, 2013, at 2:59 PM, Colin Walters wrote:
>
> > On Wed, 2013-07-17 at 13:36 -0700, Adam Williamson wrote:
> >
> >>
> >> Does 'new automatic partitioning variant' mean 'another option in the
> >> drop-down box in Installation Optio
On Jul 17, 2013, at 2:59 PM, Colin Walters wrote:
> On Wed, 2013-07-17 at 13:36 -0700, Adam Williamson wrote:
>
>>
>> Does 'new automatic partitioning variant' mean 'another option in the
>> drop-down box in Installation Options', more or less?
>
> Exactly that - at the moment.
>
> However
On Wed, 2013-07-17 at 16:59 -0400, Colin Walters wrote:
> On Wed, 2013-07-17 at 13:36 -0700, Adam Williamson wrote:
>
> >
> > Does 'new automatic partitioning variant' mean 'another option in the
> > drop-down box in Installation Options', more or less?
>
> Exactly that - at the moment.
>
> H
On Wed, 2013-07-17 at 13:36 -0700, Adam Williamson wrote:
>
> Does 'new automatic partitioning variant' mean 'another option in the
> drop-down box in Installation Options', more or less?
Exactly that - at the moment.
However...what we really lack here is some sort of explanation of the
trade
On Wed, 2013-07-17 at 12:26 +0200, Jaroslav Reznik wrote:
> = Proposed Self Contained Change: OS Installer Support for LVM Thin
> Provisioning =
> https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport
>
> Change owner(s): David Lehman
>
> LVM has introduced thin provisioni
Jaroslav Reznik (jrez...@redhat.com) said:
> = Proposed Self Contained Change: OS Installer Support for LVM Thin
> Provisioning =
> https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport
>
> Change owner(s): David Lehman
>
> LVM has introduced thin provisioning technology,
68 matches
Mail list logo
