in advance,
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jul 18, 2011 at 11:47 PM, Josef Bacik jo...@redhat.com wrote:
On 06/06/2011 06:58 PM, Nirbheek Chauhan wrote:
What can I do to debug this issue? What other information should I
supply? Could someone guide me on how to figure out why my machine is
unusable now?
I've been looking
the original
file. Similarly for removing data from the middle of a file. Would
this work? Would it be cleaner to implement something equivalent
internally?
Thanks!
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body
calculates a binary delta before transferring data, it
has to write everything out (except if just appending). So in that
case, each incremental backup is hardly so.
Thanks for your help! :)
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
--
To unsubscribe from this list: send the line unsubscribe
On Tue, Dec 7, 2010 at 1:05 AM, Freddie Cash fjwc...@gmail.com wrote:
On Mon, Dec 6, 2010 at 11:14 AM, Nirbheek Chauhan
nirbheek.chau...@gmail.com wrote:
As an aside, my primary motivation for this was that doing an
incremental backup of things like git bare repositories and databases
using
On Tue, Dec 7, 2010 at 2:12 AM, Freddie Cash fjwc...@gmail.com wrote:
On Mon, Dec 6, 2010 at 12:30 PM, Nirbheek Chauhan
nirbheek.chau...@gmail.com wrote:
But the behaviour of --inplace is not entirely to write out *only* the
blocks that have changed. From what I could make out, it does
[I think the mail was sent to just me due to a reply-accident, I've
re-added the mailing list for this reply]
On Tue, Dec 7, 2010 at 3:50 PM, David Pottage da...@electric-spoon.com wrote:
On 06/12/10 12:41, Nirbheek Chauhan wrote:
I'd like to know if there has been any discussion about adding
From: Nirbheek Chauhan nirbheek.chau...@collabora.co.uk
If the path to a given loopback file is longer than 64 characters, none of the
Btrfs-progs tools can use it. This is because the size of loopinfo.lo_name
returned by the LOOP_GET_STATUS ioctl is 64.
The attached patch fixes this by fetching
From: Nirbheek Chauhan nirbheek.chau...@collabora.co.uk
The LOOP_GET_STATUS ioctl truncates filenames to 64 characters. We should get
the backing file for a given loop device from /sys/. This is how losetup does it
as well.
---
utils.c | 26 ++
1 files changed, 14
seen quite a few obvious bugs about btrfs-progs on this list in
the past months—most of them with patches. However, I don't see them
enter any upstream git repositories.
Cheers,
--
~Nirbheek Chauhan
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
10 matches
Mail list logo