On Wed, Oct 08, 2014 at 09:13:58AM -0700, Rich Rauenzahn wrote:
On 10/8/2014 7:20 AM, Liu Bo wrote:
On Mon, Oct 06, 2014 at 07:18:06PM -0700, Rich Rauenzahn wrote:
On 10/6/2014 7:05 PM, Liu Bo wrote:
btrfs inspect-internal logical-resolve 58464632832
$ sudo btrfs inspect-internal
If one subvolume was mounted with selinux context, other subvolumes
should be able to be mounted with the same selinux context too.
Cc: Qu Wenruo quwen...@cn.fujitsu.com
Signed-off-by: Eryu Guan eg...@redhat.com
---
v2:
- redirect _scratch_mkfs output to $seqres.full to avoid trim disk message
On Thu, Oct 9, 2014 at 1:28 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping() to insert
best fitted extent map
From: Filipe David Manana fdman...@gmail.com
To: Qu Wenruo quwen...@cn.fujitsu.com
On 2014-10-08 15:11, Eric Sandeen wrote:
I was looking at Marc's post:
http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html
and it feels like there isn't exactly a cohesive, overarching vision for
repair of a corrupted btrfs filesystem.
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and force remapping of blocks with read errors. While BTRFS
technically handles both transparently on reads, it only corrects thing
on disk when
On Thu, Oct 09, 2014 at 11:53:23AM +, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and force remapping of blocks with read errors. While BTRFS
technically handles both
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and force remapping of blocks with read errors. While BTRFS
technically handles both transparently on reads, it
On Thu, Oct 09, 2014 at 08:07:51AM -0400, Austin S Hemmelgarn wrote:
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and force remapping of blocks with read
On 2014-10-09 08:12, Hugo Mills wrote:
On Thu, Oct 09, 2014 at 08:07:51AM -0400, Austin S Hemmelgarn wrote:
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct bit-rot
and
On Thu, 09 Oct 2014 08:07:51 -0400
Austin S Hemmelgarn ahferro...@gmail.com wrote:
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct
bit-rot and force remapping of
On Thu, 9 Oct 2014 12:55:50 +0100
Hugo Mills h...@carfax.org.uk wrote:
On Thu, Oct 09, 2014 at 11:53:23AM +, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct
bit-rot and force
On 2014-10-09 08:34, Duncan wrote:
On Thu, 09 Oct 2014 08:07:51 -0400
Austin S Hemmelgarn ahferro...@gmail.com wrote:
On 2014-10-09 07:53, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 07:29:23 -0400 as
excerpted:
Also, you should be running btrfs scrub regularly to correct
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 09:18:22 -0400 as
excerpted:
On 2014-10-09 08:34, Duncan wrote:
The only way a read-only
mount should be writable is if it's mounted (bind-mounted or
btrfs-subvolume-mounted) read-write elsewhere, and the write occurs to
that mount, not the
running wheezy Debian 3.16.3-2~bpo70+1 system has locked up 2 nights
in a row running rsync copying from remote to a ~100TB btrfs. Only job
running on the server, no interactive users or anything. soft locks
showed up in kern.log across many CPUs shortly before system became
non-responsive. First
Hello,
I have trouble finishing btrfs balance on five disk raid10 fs.
I added a disk to 4x3TB raid10 fs and run btrfs balance start
/mnt/b3, which segfaulted after few hours, probably because of the BUG
below. btrfs check does not find any errors, both before the balance
and after reboot (the
On Tue, Oct 07, 2014 at 04:51:11PM +0800, Qu Wenruo wrote:
+ struct btrfs_super_block *sb = fs_info-super_copy;
+ int ret = 0;
+
+ if (sb-root_level BTRFS_MAX_LEVEL) {
+ printk(KERN_ERR BTRFS: tree_root level too big: %d %d\n,
+
On Wed, Oct 08, 2014 at 01:23:41AM +0100, Marios Titas wrote:
include/uapi/linux/btrfs.h is a more logical place to put the struct
btrfs_ioctl_defrag_range_args as it is being used by the
BTRFS_IOC_DEFRAG_RANGE IOCTL which is defined in that file.
Additionally, this is where the btrfs-progs
On 10/9/14 8:49 AM, Duncan wrote:
Austin S Hemmelgarn posted on Thu, 09 Oct 2014 09:18:22 -0400 as
excerpted:
On 2014-10-09 08:34, Duncan wrote:
The only way a read-only
mount should be writable is if it's mounted (bind-mounted or
btrfs-subvolume-mounted) read-write elsewhere, and the
I will try to explain what I have done, but also try to keep it fairly
short. I installed a Linux distro that does not support installing to
btrfs to an ext4. I ran dist-upgrade to ensure that I have the latest
btrfs-tools. I upgraded the Debian kernel from 3.13 to 3.16.3. When
all this was
On 10/9/2014 12:13 AM, Liu Bo wrote:
sudo ./btrfs inspect-internal logical-resolve -v 58464632832 /
$ sudo ./btrfs inspect-internal logical-resolve -v 58464632832 /
ioctl ret=0, total_size=4096, bytes_left=4080, bytes_missing=0, cnt=0,
missed=0
I also tried -P and -s 1
Also
Never mind. I have stumbled my way into a solution.
I ran btrfs subv delete /ext2_saved. Then I ran btrfs balance start
/. That relocated 15 of 15 chunks. Now fi show shows 2.03 GB used on
each device and fi df shows 1 GB of metadata total.
Apparently, that saved ext4 subvolume was a real mess.
Its return value is useless, its single caller ignores it and can't do
anything with it anyway, since it's a workqueue task and not the task
calling filemap_fdatawrite_range (writepages) nor filemap_fdatawait_range().
Failure is communicated to such functions via start and end of writeback
with
If cow_file_range_inline() failed, when called from compress_file_range(),
we were tagging the locked page for writeback, end its writeback and unlock it,
but not marking it with an error nor setting AS_EIO in inode's mapping flags.
This made it impossible for a caller of filemap_fdatawrite_range
For compressed writes, after doing the first filemap_fdatawrite_range() we
don't get the pages tagged for writeback immediately. Instead we create
a workqueue task, which is run by other kthread, and keep the pages locked.
That other kthread compresses data, creates the respective ordered
To avoid duplicating this double filemap_fdatawrite_range() call for
inodes with async extents (compressed writes) so often.
Signed-off-by: Filipe Manana fdman...@suse.com
---
fs/btrfs/ctree.h| 1 +
fs/btrfs/file.c | 36
fs/btrfs/inode.c
On Oct 8, 2014, at 3:11 PM, Eric Sandeen sand...@redhat.com wrote:
I was looking at Marc's post:
http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html
and it feels like there isn't exactly a cohesive, overarching vision for
repair of
Tim Cuthbertson posted on Thu, 09 Oct 2014 13:58:58 -0500 as excerpted:
I ran btrfs subv delete /ext2_saved. Then I ran btrfs balance start
/.
That relocated 15 of 15 chunks. Now fi show shows 2.03 GB used on each
device and fi df shows 1 GB of metadata total.
Apparently, that saved ext4
Original Message
Subject: Re: [PATCH] btrfs: Fix and enhance merge_extent_mapping() to
insert best fitted extent map
From: Filipe David Manana fdman...@gmail.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2014年10月09日 18:27
On Thu, Oct 9, 2014 at 1:28 AM, Qu Wenruo
Chris Murphy posted on Thu, 09 Oct 2014 21:58:53 -0400 as excerpted:
I suspect it's unintended splintering, and is an artifact that will go
away. I'd rather the convoluted, fractured nature of repair go away
before the scary experimental warnings do.
Heh, agreed with everything[1], but too
On Oct 9, 2014, at 2:58 PM, Tim Cuthbertson ratch...@gmail.com wrote:
Never mind. I have stumbled my way into a solution.
I ran btrfs subv delete /ext2_saved. Then I ran btrfs balance start
/. That relocated 15 of 15 chunks. Now fi show shows 2.03 GB used on
each device and fi df shows 1
30 matches
Mail list logo
