On Fri, Nov 20, 2015 at 08:21:31AM -0500, Austin S Hemmelgarn wrote:
> On 2015-11-20 06:39, Dmitry Katsubo wrote:
> >If I may add:
> >
> >Information for "System"
> >
> > System, DUP: total=32.00MiB, used=16.00KiB
> >
> >is also quite technical, as for end user system = metadata (one can call
>
On 2015-11-20 08:27, Hugo Mills wrote:
On Fri, Nov 20, 2015 at 08:21:31AM -0500, Austin S Hemmelgarn wrote:
On 2015-11-20 06:39, Dmitry Katsubo wrote:
If I may add:
Information for "System"
System, DUP: total=32.00MiB, used=16.00KiB
is also quite technical, as for end user system =
Many thanks to Duncan for such a verbose clarification. I am thinking
about another parallel similar to SimSity, and that is memory management
in virtual machines like Java. If heap is full, it does not really mean
that there is no free memory. In this case JVM forces garbage collector
and if
On 2015-11-20 06:39, Dmitry Katsubo wrote:
If I may add:
Information for "System"
System, DUP: total=32.00MiB, used=16.00KiB
is also quite technical, as for end user system = metadata (one can call
it "filesystem metadata" perhaps). For simplicity the numbers can be
added to "Metadata"
Am 20.11.2015 um 04:14 schrieb Duncan:
> Meta-comment:
>
> Apparently that attribution should actually be to Hugo Mills. I've no
> idea what went wrong, but at least here as received from gmane.org, the
> from header really does say linux-btrfs.tebulin, so something obviously
> bugged out
If I may add:
Information for "System"
System, DUP: total=32.00MiB, used=16.00KiB
is also quite technical, as for end user system = metadata (one can call
it "filesystem metadata" perhaps). For simplicity the numbers can be
added to "Metadata" thus eliminating that line as well.
For those
On 2015-11-19 21:11, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 19 Nov 2015 07:28:34 -0500 as
excerpted:
(having all updates installed on Ubuntu doesn't really count in this
case, they're pretty bad sometimes about not properly tracking upstream
development[)]
No kidding. I'm involved
linux-btrfs.tebulin posted on Fri, 20 Nov 2015 10:38:33 +0100 as
excerpted:
> Am 20.11.2015 um 04:14 schrieb Duncan:
>> Meta-comment:
>>
>> Apparently that attribution should actually be to Hugo Mills. I've no
>> idea what went wrong, but at least here as received from gmane.org, the
>> from
On 2015-11-20 14:52, Austin S Hemmelgarn wrote:
> On 2015-11-20 08:27, Hugo Mills wrote:
>> On Fri, Nov 20, 2015 at 08:21:31AM -0500, Austin S Hemmelgarn wrote:
>>> On 2015-11-20 06:39, Dmitry Katsubo wrote:
For those power users who really want to see the tiny details like
"System" and
On 19 November 2015 at 06:58, Roman Mamedov wrote:
>
> On Wed, 18 Nov 2015 19:53:03 +0100
> linux-btrfs.tebu...@xoxy.net wrote:
>
> > $ uname -a
> > Linux neptun 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8
> > 10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[...]
>
>
This explanation helped a lot. Got it now!
Thank you!
>You start with a load of unused space -- that's the "total" for
> each device in btrfs fi show. That space is allocated to specific
> usages as the FS needs it. The allocated space is the "used" in btrfs
> fi show for each device.
>
>
>It's just freed up lots of space. You'll probably find that your
> "total" value for data in btrfs fi df is close to (but not exactly) 66
> GiB now, if you've just run a full unfiltered balance. (The difference
> being made up of metadata).
I think i need to dive more into the details of
On Thu, Nov 19, 2015 at 07:45:13PM +0100, Ben Tebulin wrote:
>
> >It's just freed up lots of space. You'll probably find that your
> > "total" value for data in btrfs fi df is close to (but not exactly) 66
> > GiB now, if you've just run a full unfiltered balance. (The difference
> > being
On 2015-11-19 13:28, Hugo Mills wrote:
On Thu, Nov 19, 2015 at 06:35:24PM +0100, linux-btrfs.tebu...@xoxy.net wrote:
Will newer kernels do the balance on their own?
I think it's on the "projects" list on the wiki, so it may get done
eventually. As I said above, I'm not aware of anyone
On 2015-11-18 13:53, linux-btrfs.tebu...@xoxy.net wrote:
P.S.: Just as user feedback: For /srv I'm using on the very same system
ZFS since the very first day. With snapshots & all the fancy stuff like
ZRAID-1, lz4, ... My number of Issues there: 0
Since other people have adequately answered the
Austin S Hemmelgarn posted on Thu, 19 Nov 2015 07:28:34 -0500 as
excerpted:
> (having all updates installed on Ubuntu doesn't really count in this
> case, they're pretty bad sometimes about not properly tracking upstream
> development[)]
No kidding. I'm involved with an upstream that had a
linux-btrfs.tebulin posted on Thu, 19 Nov 2015 18:56:45 + as
excerpted:
Meta-comment:
Apparently that attribution should actually be to Hugo Mills. I've no
idea what went wrong, but at least here as received from gmane.org, the
from header really does say linux-btrfs.tebulin, so something
On Wed, Nov 18, 2015 at 07:53:03PM +0100, linux-btrfs.tebu...@xoxy.net wrote:
> Hello there!
>
> I'm stumbling over this regularly. I explicitly upgraded the kernel to
> avoid this, but it still occurs me every few months:
>
> $ touch foo
> touch: »foo“ kann nicht berührt werden: Auf dem
Hugo Mills wrote on 2015/11/18 19:08 +:
On Wed, Nov 18, 2015 at 07:53:03PM +0100, linux-btrfs.tebu...@xoxy.net wrote:
Hello there!
I'm stumbling over this regularly. I explicitly upgraded the kernel to
avoid this, but it still occurs me every few months:
$ touch foo
touch: »foo“
Qu Wenruo posted on Thu, 19 Nov 2015 08:42:13 +0800 as excerpted:
> Although the metadata output is showing that you still have about 512M
> available, but the 512M is Global Reserved space, or the unknown one.
Unknown here, as the userspace (btrfs-progs) is evidently too old to show
it as
On Wed, 18 Nov 2015 19:53:03 +0100
linux-btrfs.tebu...@xoxy.net wrote:
> $ uname -a
> Linux neptun 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8
> 10:21:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
For whatever unknown reason, Ubuntu repeatedly chooses to stabilize on exactly
the wrong
21 matches
Mail list logo