Dear list,
Is there a way to find out what btrfs device delete is doing, and how
far it has come? I know there's no status command, but I'm thinking it
might be possible to obtain something via some other channel, such as
btrfs fi df and btrfs fi show, which I have been using to try and
Thank you very much for the reply. That clarifies a lot of things.
I was trying a small test case that opens a file, writes a block of
data, calls fsync and then closes the file. If I understand correctly,
fsync would return only after all in-memory buffers have been
committed to disk. I have
On Sun, Sep 29, 2013 at 11:22:36AM +0200, Aastha Mehta wrote:
Thank you very much for the reply. That clarifies a lot of things.
I was trying a small test case that opens a file, writes a block of
data, calls fsync and then closes the file. If I understand correctly,
fsync would return only
+printf(\tUnshared space: \t%s\n,
+pretty_size(freeable_bytes));
There's no reason to have a local variable:
printf(\tUnshared space: \t%s\n,
pretty_size(get_subvol_freeable_bytes(fd));
this is taken care.
These two fiddly functions only differ in the tree
as of now, when 'btrfs device add' adds a device it doesn't
check if the given device contains an existing FS. This
patch will change that to check the same. which when true
add will fail, and ask user to use -f option to overwrite.
further, since now we have test_dev_for_mkfs() function
to check
It needs a lot more information about the snapshots if
snapshot's life cycle has to be all auto managed by
scripts _some day_. this patch is a step towards that.
This patch provides the size which would be freed
if the subvol/snapshot is deleted.
preview:
-
btrfs su show
wrong patch sent. Please ignore this. sorry.
On 09/29/2013 11:15 PM, Anand Jain wrote:
as of now, when 'btrfs device add' adds a device it doesn't
check if the given device contains an existing FS. This
patch will change that to check the same. which when true
add will fail, and ask user to
On 29/09/13 06:11, Duncan wrote:
Martin posted on Sun, 29 Sep 2013 03:10:37 +0100 as excerpted:
So...
Any options for btrfsck to fix things?
Or is anything/everything that is fixable automatically fixed on the
next mount?
Or should:
btrfs scrub /dev/sdX
be run first?
Or?
What
On 29/09/13 22:29, Martin wrote:
Looking up what's available for Gentoo, the maintainers there look to be
nicely sharp with multiple versions available all the way up to kernel
3.11.2...
That is being pulled in now as expected:
sys-kernel/gentoo-sources-3.11.2
There's also the latest
