On Fri, 06 Sep 2013 11:08:16 +0800, Miao Xie wrote:
Onthu, 5 Sep 2013 16:58:43 +0200, Stefan Behrens wrote:
The fact that btrfs_root_refs() returned 0 for the tree_root caused
bugs in the past, therefore it is set to 1 with this patch and
(hopefully) all affected code is adapted to this
Now with the below kernel patch, the excl operations like dev
add/replace/resize and balance returns the btrfs error
code defined in btrfs.h, this patch will help btrfs-progs
(and thus user) to know the error string on the terminal
(instead of /var/log/messages as previously kernel did).
This
This is a prepatory work for the following btrfs fi show command
fixes. So that we have a function get_df to get the fs sizes
v4:
fixes checkpatch.pl errors as suggested by Wang
v3:
accepts Zach review comments
v2:
combined the other patches as below and rebase
btrfs-progs: get string for the
As of now btrfs filesystem show reads directly from
disks. So sometimes output can be stale, mainly when
user want to verify their last operation like,
labeling or device delete or add... etc. so this
patch will read from the kernel ioctl if it finds
that disk is mounted.
Further, to scan for the
when the balance is running, the replace start ioctl
fails (for the right reasons). but since the cli has
put ioctl thread to background (for right reasons)
the user won't know that cli failed to start.
so before cli goes to the background, it should check
if mutually_exclusive_operation_running
this there is commit error. Kindly ignore this.
I have sent out a new patch for this.
Thanks, Anand
On 09/02/2013 10:55 AM, Anand Jain wrote:
when the balance is running, the replace start ioctl
fails (for the right reasons). but since the cli has
put ioctl thread to background (for right
A user reported a problem with his fs where he had a bogus isize on his
directory. In order to make sure my patch for fsck fixes this properly I needed
to be able to corrupt an inode like this, which is what this patch is for.
Eventually I want to extend this to corrupt everything so we can
On Fri, 30 Aug 2013 18:35:34 +0800, Miao Xie wrote:
By the current code, if the requested size is very large, and all the extents
in the free space cache are small, we will waste lots of the cpu time to cut
the requested size in half and search the cache again and again until it gets
down to
On Tue, Sep 03, 2013 at 06:19:01PM -0400, Jeff Mahoney wrote:
The DEVHTL lookup in btrfs/003 is broken. It can only handle full LUNs and
not partitions on a disk.
Rather than returning 2:0:0:0 for /dev/sdc7, it returns 'block' and we see:
./common/rc: line 2081:
On 9/6/13 10:03 AM, David Sterba wrote:
On Tue, Sep 03, 2013 at 06:19:01PM -0400, Jeff Mahoney wrote:
The DEVHTL lookup in btrfs/003 is broken. It can only handle full LUNs and
not partitions on a disk.
Rather than returning 2:0:0:0 for /dev/sdc7, it returns 'block' and we see:
./common/rc:
A user had a corrupt fs where one of his file extents pointed to a completely
bogus disk bytenr. This patch allows us to corrupt a file system in a similar
way in order to test btrfsck. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
btrfs-corrupt-block.c | 117
We need to start adding some sanity tests to btrfs-progs to make sure we aren't
breaking things with our patches. The most important of these tools is btrfsck.
This patch gets things started by adding a basic btrfsck test that makes sure we
can fix a corruption problem we know we can fix.
Hi,
I have run:
find / -xdev \( -type f -o -type d \) -exec btrfs filesystem defragment -v
-- {} +
On Ubuntu 13.04 with kernel 3.11 from root recovery shell after remounting
rw /
This is the dmesg output:
[17788.691504] [ cut here ]
[17788.691510] [ cut here
Hi,
Because of being clumsy, I recently overwrote my btrfs-partition.
Worse, the only recent backup I own is a dd-copy which was created
while the system was running.
Both, btrfsck (from btrfsprogs-next) and mount -o recovery failed - so
I wonder, are there any steps left I could try?
14 matches
Mail list logo
