On Tue, Feb 18, 2014 at 09:33:17AM +0100, Goswin von Brederlow wrote:
> > The size of global block reserve should be IMO subtracted from 'avail',
> > this reports the space as free, but is in fact not.
>
> How much global block reserve is there? Does that explain why I can't
> use the last 270G of
On Mon, Feb 17, 2014 at 06:08:20PM +0100, David Sterba wrote:
> On Mon, Feb 10, 2014 at 01:41:23PM -0500, Josef Bacik wrote:
> >
> >
> > On 02/10/2014 01:36 PM, cwillu wrote:
> > >IMO, used should definitely include metadata, especially given that we
> > >inline small files.
> > >
> > >I can conv
On Mon, Feb 10, 2014 at 01:41:23PM -0500, Josef Bacik wrote:
>
>
> On 02/10/2014 01:36 PM, cwillu wrote:
> >IMO, used should definitely include metadata, especially given that we
> >inline small files.
> >
> >I can convince myself both that this implies that we should roll it
> >into b_avail, and
Hi Kostia,
On 02/12/2014 04:09 AM, Kostia Khlebopros wrote:
> Any plans on having "brtfs fi df" report more precise values rather
> then rounded off to the nearest hundredth of a unit. full
> kilobytes(1024 bytes =1Kib) or in bytes would be nice>
> Current output:
>
> # btrfs fi df /data
> Data,
Hi Hugo,
On 02/11/2014 07:56 PM, Hugo Mills wrote:
>> $ sudo btrfs filesystem df /mnt/btrfs1/
>> Disk size:400.00GB
>> Disk unallocated: 391.97GB
>> Disk allocation:
>> AllocatedUsed
>>Data, single: 2.01GB, 1.00GB
>>System, DUP
Most of the btrfs-progs output has to be (re)designed from the point
of view of the end-user.
Eg: 'btrfs su list /mnt', it could have been much better from the end
user perspective (who does not have to look into the source code),
of course it does make sense to the developers himself but
54 PM
To: linux-btrfs@vger.kernel.org
Cc: Josef Bacik
Subject: Re: What to do about df and btrfs fi df
Maybe this is too much of a break from tradition but I think df should report
the min(device free space, remaining quota) for the particular volume being
queried.
On Mon, Feb 10, 2014 at 11:41
Maybe this is too much of a break from tradition but I think df should
report the min(device free space, remaining quota) for the particular
volume being queried.
On Mon, Feb 10, 2014 at 11:41 AM, Josef Bacik wrote:
> Hello,
>
> So first of all this is going to get a lot of responses, so straigh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/02/14 19:13, cwillu wrote:
> But the answer changes dramatically depending on whether it's large
> numbers of small files or a small number of large files, and the
> conservative worst-case choice means we report a number that is half
> what i
On Tue, Feb 11, 2014 at 07:20:23PM +0100, Goffredo Baroncelli wrote:
> On 02/11/2014 02:14 PM, Josef Bacik wrote:
> >
> >
> > On 02/10/2014 05:26 PM, Goffredo Baroncelli wrote:
> >> On 02/10/2014 05:41 PM, Josef Bacik wrote:
> >>> = New and improved btrfs fi df =
> [...]
>
> Hi Josef
>
On 02/11/2014 07:33 PM, Josef Bacik wrote:
>
>
> On 02/11/2014 01:20 PM, Goffredo Baroncelli wrote:
>> On 02/11/2014 02:14 PM, Josef Bacik wrote:
>>>
>>>
>>> On 02/10/2014 05:26 PM, Goffredo Baroncelli wrote:
On 02/10/2014 05:41 PM, Josef Bacik wrote:
> = New and improved btrfs fi df
On 02/11/2014 01:20 PM, Goffredo Baroncelli wrote:
On 02/11/2014 02:14 PM, Josef Bacik wrote:
On 02/10/2014 05:26 PM, Goffredo Baroncelli wrote:
On 02/10/2014 05:41 PM, Josef Bacik wrote:
= New and improved btrfs fi df =
[...]
Hi Josef
The problem I had with this patch was it d
On 02/11/2014 02:14 PM, Josef Bacik wrote:
>
>
> On 02/10/2014 05:26 PM, Goffredo Baroncelli wrote:
>> On 02/10/2014 05:41 PM, Josef Bacik wrote:
>>> = New and improved btrfs fi df =
[...]
Hi Josef
> The problem I had with this patch was it didn't give me a way to get
> the original out
On Mon, Feb 10, 2014 at 01:41:23PM -0500, Josef Bacik wrote:
> On 02/10/2014 01:36 PM, cwillu wrote:
> >IMO, used should definitely include metadata, especially given that we
> >inline small files.
> >
> >I can convince myself both that this implies that we should roll it
> >into b_avail, and that
On 02/10/2014 05:26 PM, Goffredo Baroncelli wrote:
On 02/10/2014 05:41 PM, Josef Bacik wrote:
= New and improved btrfs fi df =
Since people using this tool are already going to be better informed
and since we are already given the block group flags we can go ahead
and do the raid mult
On Mon, Feb 10, 2014 at 7:13 PM, cwillu wrote:
> On Mon, Feb 10, 2014 at 7:02 PM, Roger Binns wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/02/14 10:24, cwillu wrote:
>>> The regular df data used number should be the amount of space required
>>> to hold a backup of that c
On Mon, Feb 10, 2014 at 7:02 PM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/02/14 10:24, cwillu wrote:
>> The regular df data used number should be the amount of space required
>> to hold a backup of that content (assuming that the backup maintains
>> reflinks a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/02/14 10:24, cwillu wrote:
> The regular df data used number should be the amount of space required
> to hold a backup of that content (assuming that the backup maintains
> reflinks and compression and so forth).
>
> There's no good answer for
> In the past [1] I proposed the following approach.
>
> $ sudo btrfs filesystem df /mnt/btrfs1/
> Disk size: 400.00GB
> Disk allocated:8.04GB
> Disk unallocated:391.97GB
> Used: 11.29MB
> Free (Estimated):250.45GB (Max: 396.99GB,
On 02/10/2014 05:41 PM, Josef Bacik wrote:
> = New and improved btrfs fi df =
>
> Since people using this tool are already going to be better informed
> and since we are already given the block group flags we can go ahead
> and do the raid multiplier in btrfs-progs and spit out the adjuste
On 02/10/2014 06:06 PM, Hugo Mills wrote:
>Biggest multiplier leads to the pessimistic estimate, which is what
> I'd prefer to see here, so that's good. Agree with this.
I would prefer to use as "raid multiplier" the ratio
total data block groups + total metadata block group
---
On Mon, Feb 10, 2014 at 01:41:23PM -0500, Josef Bacik wrote:
>
>
> On 02/10/2014 01:36 PM, cwillu wrote:
> >IMO, used should definitely include metadata, especially given that we
> >inline small files.
> >
> >I can convince myself both that this implies that we should roll it
> >into b_avail, and
>> IMO, used should definitely include metadata, especially given that we
>> inline small files.
>>
>> I can convince myself both that this implies that we should roll it
>> into b_avail, and that we should go the other way and only report the
>> actual used number for metadata as well, so I might
On 02/10/2014 01:36 PM, cwillu wrote:
IMO, used should definitely include metadata, especially given that we
inline small files.
I can convince myself both that this implies that we should roll it
into b_avail, and that we should go the other way and only report the
actual used number for meta
IMO, used should definitely include metadata, especially given that we
inline small files.
I can convince myself both that this implies that we should roll it
into b_avail, and that we should go the other way and only report the
actual used number for metadata as well, so I might just plead
insani
On 02/10/2014 01:24 PM, cwillu wrote:
I concur.
The regular df data used number should be the amount of space required
to hold a backup of that content (assuming that the backup maintains
reflinks and compression and so forth).
There's no good answer for available space; the statfs syscall is
I concur.
The regular df data used number should be the amount of space required
to hold a backup of that content (assuming that the backup maintains
reflinks and compression and so forth).
There's no good answer for available space; the statfs syscall isn't
rich enough to cover all the bases eve
tl;dr: Yes to proposed df changes. Keep btrfs fi df as-is.
On Mon, Feb 10, 2014 at 11:41:51AM -0500, Josef Bacik wrote:
[snip]
> = What to do moving forward =
>
> Flip what both of these do. Do not multiply for normal df, and
> multiply for btrfs fi df.
>
> = New and improved df ==
Hello,
So first of all this is going to get a lot of responses, so straight
away I'm only going to consider your opinion if I recognize your name
and think you are a sane person. This basically means any big
contributors and we'll make sanity exceptions for cwillu.
These are just broad stro
29 matches
Mail list logo
