On Thu, Jul 16, 2015 at 01:12:03PM +1000, Paul Harvey wrote:
> On 16 July 2015 at 11:35, Chris Murphy wrote:
> > On Wed, Jul 15, 2015 at 6:11 PM, Johannes Ernst
> > wrote:
> >
> >> Cleaning this all up is a bit of pain, and
> >> btrfs subvolume delete -r dir
> >> would solve it nicely.
>
From: Zhao Lei
When mount failed because missing device, we can see following
dmesg:
[ 1060.267743] BTRFS: too many missing devices, writeable mount is not allowed
[ 1060.273158] BTRFS: open_ctree failed
This patch add missing_device_number and tolerated_missing_device_number
to above output,
From: Zhao Lei
1: Use ARRAY_SIZE(types) to replace a static-value variant:
int num_types = 4;
2: Use 'continue' on condition to reduce one level tab
if (!XXX) {
code;
...
}
->
if (XXX)
continue;
code;
...
3: Put setting 'num_tolerated_disk_barrier_failu
From: Filipe Manana
We have another case where after an fsync log replay we get an inode with
a wrong link count (smaller than it should be) and a number of directory
entries greater than its link count. This happens when we add a new link
hard link to our inode A and then we fsync some other ino
From: Filipe Manana
Test that if we add hard links (in the same directory) to two files and
then fsync only one of the files, after the fsync log/journal is replayed
all the links exist and the filesystem metadata (directory and file
inodes) is in a consistent state.
This test is motivated by a
On Wed, Jul 15, 2015 at 11:59:27PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that if we add hard links (in the same directory) to two files and
> then fsync only one of the files, after the fsync log/journal is replayed
> all the links exist and the filesystem metadata (dir
On Wed, Jul 15, 2015 at 11:48:14AM +0800, Zhaolei wrote:
> From: Zhao Lei
>
> Liu Bo reported a lockdep warning of
> delayed_iput_sem in xfstests generic/241:
> [ 2061.345955] =
> [ 2061.346027] [ INFO: possible recursive locking detected ]
> [ 2
On 2015-07-15 17:29, Chris Murphy wrote:
On Wed, Jul 15, 2015 at 10:15 AM, Hugo Mills wrote:
There is at least one superblock on every device, usually two, and
often three. Each superblock contains the virtual address of the roots
of the root tree, the chunk tree and the log tree. Those ar
On 2015-07-14 07:49, Austin S Hemmelgarn wrote:
So, after experiencing this same issue multiple times (on almost a dozen
different kernel versions since 4.0) and ruling out the possibility of it being
caused by my hardware (or at least, the RAM, SATA controller and disk drives
themselves), I'v
From: Zhao Lei
Code for updating fs_info->num_tolerated_disk_barrier_failures in
btrfs_balance() lacks raid56 support.
Reason:
Above code was wroten in 2012-08-01, together with
btrfs_calc_num_tolerated_disk_barrier_failures()'s first version.
Then, btrfs_calc_num_tolerated_disk_barrier_fail
On 16 July 2015 at 17:59, Hugo Mills wrote:
> On Thu, Jul 16, 2015 at 01:12:03PM +1000, Paul Harvey wrote:
>> I for one would love to see authoritative documentation on "proper"
>> subvolume organization. I was completely lost when writing snazzer and
>> have so far received very little guidance o
On Thu, Jul 16, 2015 at 4:06 AM, Paul Harvey wrote:
> On Thu, 16 Jul 2015 17:59 Hugo Mills wrote:
>
>
>>
>> On Thu, Jul 16, 2015 at 01:12:03PM +1000, Paul Harvey wrote:
>> > On 16 July 2015 at 11:35, Chris Murphy wrote:
>> > > On Wed, Jul 15, 2015 at 6:11 PM, Johannes Ernst
>> > > wrote:
>> > >
Hi all,
While I'm developing a new btrfs inband dedup mechanism, I found btrfsck
and kernel doing strange behavior for clone.
[Reproducer]
# mount /dev/sdc -t btrfs /mnt/test
# dd if=/dev/zero of=/mnt/test/file1 bs=4K count=4
# sync
# ~/xfstests/src/cloner -s 4096 -l 4096 /mnt/test/file1 /mnt/
On Sun, May 3, 2015 at 2:56 AM, Filipe Manana wrote:
> Marc reported a problem where the receiving end of an incremental send
> was performing clone operations that failed with -EINVAL. This happened
> because, unlike for uncompressed extents, we were not checking if the
> source clone offset and
When running generic/311 on Btrfs' subpagesize-blocksize patchset (on ppc64
with 4k sectorsize and 16k node/leaf size) I noticed the following call trace,
BTRFS (device dm-0): parent transid verify failed on 29720576 wanted 160 found
158
BTRFS (device dm-0): parent transid verify failed on 297205
15 matches
Mail list logo