Maybe you mean du? df takes almost no time at all and does not care
how many files there are.
Yep, I certainly meant du there.
Just be carefull, because for example if you use -o compress, the space
the files are actually using can be different...
Certainly, one more reason why btrfs
Hi, all. I was copying two 6-GB DVD images yesterday, and while
monitoring the copy progress, noticed that du would show a trend that
*generally* headed toward the final files' sizes, but on occasion would
hop backward, thusly:
r...@hal-9000:/shared/ISOs# while true; do du * ; sleep 10;
Hello
Actually I have problem with run mysql (InnoDB db backend) on btrfs file
system.
MySql daemon doesn’t run and log file contains:
101006 13:36:39 mysqld started
InnoDB: Error: tried to read 16384 bytes at offset 0 0.
InnoDB: Was only able to read -1.
101006 13:36:40 InnoDB: Operating system
Written against the btrfs-unstable git tree, the attached patch
installs cleanly against the latest kernel (as of two weeks ago.)
The patches for btrfsctl and btrfs programs will be coming soon; I'm
adding support for ISO8061 duration strings instead of (or in addition
to) milliseconds and
On Wednesday, 06 October, 2010, David Nicol wrote:
[..]
Btrfsctl apparently allows several operations to be presented as one
set of command line arguments, sort of like find(1) does; would
someone who does that a lot please respond off-list to discuss the
ideal semantics of new commands?
Hi,
On Wed, Oct 6, 2010 at 11:05 AM, David Nicol davidni...@gmail.com wrote:
The patches for btrfsctl and btrfs programs will be coming soon; I'm
adding support for ISO8061 duration strings instead of (or in addition
to) milliseconds and thinking about switching the order of the two
args to
Running some multi-threaded writer tests with mixed block groups I was noticing
that I hit ENOSPC really quickly. There were a few problems
1) If we tried to use some space and couldn't, we'd try and reclaim. The
problem is we aren't holding onto our reservation, so it just means that other
There are just a few things that need to be fixed in the kernel to support mixed
data+metadata block groups. Mostly we just need to make sure that if we are
using mixed block groups that we continue to allocate mixed block groups as we
need them. Also we need to make sure __find_space_info will
the ISO 8601 duration support is very loose, but I believe it is
accurate for valid
input. Without any non-numeric designators, the timeout is interpreted
as seconds,
so
btrfs fi reclaim 10.3321 /my_btrfs_mount || echo timed out
will wait 10332 ms before echoing, if the pending subvolume
