Hi Chris,
Thanks for commenting. Some clarifying comments as below.
On 30/09/2014 22:23, Chris Mason wrote:
On Mon, Sep 29, 2014 at 1:09 AM, Anand Jain wrote:
From: Anand Jain
(added RFC prefix to the patch header)
(as of now just an experimental interface)
This patch introduces profs
On Fri, Sep 05, 2014 at 11:51:24PM +0800, Anand Jain wrote:
> +static void wipe_existing_fs(int fd)
> +{
...
> + blkid_probe_enable_partitions(pr, 1);
> +
> + while (blkid_do_probe(pr) == 0)
> + blkid_do_wipe(pr, 0);
Reported by a user on IRC, I verified it on one of my old tes
On 10/01/2014 07:26 PM, David Sterba wrote:
On Fri, Sep 05, 2014 at 11:51:24PM +0800, Anand Jain wrote:
+static void wipe_existing_fs(int fd)
+{
...
+ blkid_probe_enable_partitions(pr, 1);
+
+ while (blkid_do_probe(pr) == 0)
+ blkid_do_wipe(pr, 0);
Reported by a u
On Wed, Oct 1, 2014 at 3:41 AM, Anand Jain
wrote:
Hi Chris,
Thanks for commenting. Some clarifying comments as below.
On 30/09/2014 22:23, Chris Mason wrote:
On Mon, Sep 29, 2014 at 1:09 AM, Anand Jain
wrote:
From: Anand Jain
(added RFC prefix to the patch header)
(as of now just an
Fsck only cares if the cache is really broken, so don't be noisy if the
generations don't match or other such errors. Thanks,
Signed-off-by: Josef Bacik
---
free-space-cache.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/free-space-cache.c b/free-space-cach
From: Josef Bacik
We have --init-csum-tree, which just empties the csum tree. I'm not sure why we
would ever need this, but we definitely need to be able to rebuild the csum tree
in some cases. This patch adds the ability to completely rebuild the crc tree
by reading all of the data and adding
We have --init-csum-tree, which just empties the csum tree. I'm not sure why we
would ever need this, but we definitely need to be able to rebuild the csum tree
in some cases. This patch adds the ability to completely rebuild the crc tree
by reading all of the data and adding csum entries for the
On Fri, Sep 26, 2014 at 3:36 AM, Qu Wenruo
wrote:
When btrfs-progs walk down the tree, it does not check whether the
child
node/leaf is valid.
In fact, there is some corrupted image whose csum is all valid but
parent node points to a invalid leaf.
In my case, the parent node in fs tree point t
Hi,
several important fixes appeared recently and the 3.17 branch is not
finalized so I'm doing another minor release, including nonintrusive
patches and documentation updates.
Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/
Git: https://git.kernel.org/cgit/linux/kerne
A user had a corrupted fs where the items had been shifted improperly. This
patch adds the ability to fix this sort of problem within fsck. We will simply
shift the item over to the proper offset and update the offsets to make sure
they are correct. I tested this with a hand crafted fs that was
What I forgot to mention:
`uname -r`: 3.17.0-0.rc6.git2.1.fc22.x86_64
`btrfs --version`: Btrfs v3.16
regards,
Niklas
Am 01.10.2014 um 22:29 schrieb Niklas Fischer:
> Hello,
>
> I was trying to determine how btrfs reacts to disk errors, when I
> discovered, that flipping two Bytes, supposedly in
Hello,
I was trying to determine how btrfs reacts to disk errors, when I
discovered, that flipping two Bytes, supposedly inside of a file can
render the filesystem unusable. Here is what I did:
1. dd if=/dev/zero of=/dev/sdg2 bs=1M
2. mkfs.btrfs /dev/sdg2
3. mount /dev/sdg2 /tmp/btrfs
4. echo "he
Chris Mason posted on Wed, 01 Oct 2014 10:09:12 -0400 as excerpted:
>>> We're going to have a really hard time getting a new proc interface
>>> merged in, and after we've recently fixed up all (most?) of our sysfs
>>> races, I'd rather not have to do it all over again with /proc.
>>
>> This does
David Sterba posted on Wed, 01 Oct 2014 18:49:10 +0200 as excerpted:
> several important fixes appeared recently and the 3.17 branch is not
> finalized so I'm doing another minor release, including nonintrusive
> patches and documentation updates.
In 3.16.1 I looked in vain for documentation for
Niklas Fischer posted on Wed, 01 Oct 2014 22:29:55 +0200 as excerpted:
> I was trying to determine how btrfs reacts to disk errors, when I
> discovered, that flipping two Bytes, supposedly inside of a file can
> render the filesystem unusable. Here is what I did:
>
> 1. dd if=/dev/zero of=/dev/sd
Others might be thinking this to so I better ask:
Does this just read the first copy in the case of dup, raid1, etc. and plow on?
I'm
not sure how you would handle a mismatch due to a hardware error.
Perhaps read all the copies and create another subvolume containing the
mismatched copies?
Than
I'm experimenting with btrfs-send. Previously (2014-09-26), I did my
first btrfs-send on a subvol, and that worked fine. Today, I tried to
send a new snapshot. Unfortunately, I realized part way through that I
forgot to specify the parent to only send a delta, and killed the send
with ^C.
On the d
On 2014/10/02 01:31, Duncan wrote:
Niklas Fischer posted on Wed, 01 Oct 2014 22:29:55 +0200 as excerpted:
I was trying to determine how btrfs reacts to disk errors, when I
discovered, that flipping two Bytes, supposedly inside of a file can
render the filesystem unusable. Here is what I did:
1
On Thu, Oct 02, 2014 at 12:05:39AM -0500, Justin Brown wrote:
> I'm experimenting with btrfs-send. Previously (2014-09-26), I did my
> first btrfs-send on a subvol, and that worked fine. Today, I tried to
> send a new snapshot. Unfortunately, I realized part way through that I
> forgot to specify t
19 matches
Mail list logo
