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 anand.j...@oracle.com wrote:
From: Anand Jain anand.j...@oracle.com
(added RFC prefix to the patch header)
(as of now just an
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 test
From: Josef Bacik jba...@fusionio.com
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
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
On Fri, Sep 26, 2014 at 3:36 AM, Qu Wenruo quwen...@cn.fujitsu.com
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
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:
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
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
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 not use
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/sdg2
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?
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
14 matches
Mail list logo
