Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By doing this we prevent intentional or accidental

Re: [PATCH v3] btrfs: relocation: Enhance kernel error output for relocation

Any comment on this patch? Thanks, Qu At 02/15/2017 09:39 AM, Qu Wenruo wrote: When balance(relocation) fails, btrfs-progs will report like: ERROR: error during balancing '/mnt/scratch': Input/output error There may be more info in syslog - try dmesg | tail However kernel can't provide may

[PATCH v6 2/2] btrfs: Handle delalloc error correctly to avoid ordered extent hang

[BUG] If run_delalloc_range() returns error and there is already some ordered extents created, btrfs will be hanged with the following backtrace: Call Trace: __schedule+0x2d4/0xae0 schedule+0x3d/0x90 btrfs_start_ordered_extent+0x160/0x200 [btrfs] ? wake_atomic_t_function+0x60/0x60

[PATCH v6 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error

[BUG] When btrfs_reloc_clone_csum() reports error, it can underflow metadata and leads to kernel assertion on outstanding extents in run_delalloc_nocow() and cow_file_range(). BTRFS info (device vdb5): relocating block group 12582912 flags data BTRFS info (device vdb5): found 1 extents

Re: Why do BTRFS (still) forgets what device to write to?

waxhead posted on Sun, 05 Mar 2017 17:26:36 +0100 as excerpted: > I am doing some test on BTRFS with both data and metadata in raid1. > > uname -a Linux daffy 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) > x86_64 GNU/Linux > > btrfs--version btrfs-progs v4.7.3 > > > 01. mkfs.btrfs

Re: [PATCH v2] btrfs-progs: report I/O errors when closing the filesystem

At 03/04/2017 01:02 AM, Omar Sandoval wrote: From: Omar Sandoval If the final fsync() on the Btrfs device fails, we just swallow the error and don't alert the user in any way. This was uncovered by xfstest generic/405, which checks that mkfs fails when it encounters EIO.

Re: [PATCH] btrfs-progs: report I/O errors when closing the filesystem

At 03/04/2017 12:59 AM, Omar Sandoval wrote: From: Omar Sandoval If the final fsync() on the Btrfs device fails, we just swallow the error and don't alert the user in any way. This was uncovered by xfstest generic/405, which checks that mkfs fails when it encounters EIO.

Re: [PATCH 00/17] fs, btrfs refcount conversions

At 03/03/2017 04:55 PM, Elena Reshetova wrote: Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the btrfs filesystem from atomic_t to refcount_t. By doing this we prevent intentional or accidental

Re: [4.7.2] btrfs_run_delayed_refs:2963: errno=-17 Object already exists

On Mittwoch, 1. März 2017 19:14:07 CET you wrote: > In any > case, I started btrfs-check on the device itself. *Sigh*, I had to restart it, because I forgot to redirect to a file and quite frankly wasn't expecting this flood of output, but here's a summary of the output after about 2 days: %

Re: BTRFS critical: corrupt leaf, slot offset bad; then read-only

Hello Hans, Am 24.02.2017 um 01:26 schrieb Hans van Kranenburg: Once that is done, I would like to go over the "btrfs recovery" thread and see if it can be applied for my case as well. I will certainly need your help when that time comes... We can take a stab at it. I upgraded

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

[ ... on the difference between number of devices and length of a chunk-stripe ... ] > Note: possibilities get even more interesting with a 4-device > volume with 'raid1' profile chunks, and similar case involving > other profiles than 'raid1'. Consider for example a 4-device volume with 2

Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

>> What makes me think that "unmirrored" 'raid1' profile chunks >> are "not a thing" is that it is impossible to remove >> explicitly a member device from a 'raid1' profile volume: >> first one has to 'convert' to 'single', and then the 'remove' >> copies back to the remaining devices the 'single'

assertion failed: page_ops & PAGE_LOCK

After commenting out the assertion that Liu bo pointed out was bogus, my trinity runs last a little longer.. This is a new one I think.. assertion failed: page_ops & PAGE_LOCK, file: fs/btrfs/extent_io.c, line: 1716 [ cut here ] kernel BUG at fs/btrfs/ctree.h:3423! invalid

Why do BTRFS (still) forgets what device to write to?

I am doing some test on BTRFS with both data and metadata in raid1. uname -a Linux daffy 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux btrfs--version btrfs-progs v4.7.3 01. mkfs.btrfs /dev/sd[fgh]1 02. mount /dev/sdf1 /btrfs_test/ 03. btrfs balance start -dconvert=raid1

Re: [PATCH 0/8 v2] Non-blocking AIO

On 03/01/2017 01:36 AM, Goldwyn Rodrigues wrote: This series adds nonblocking feature to asynchronous I/O writes. io_submit() can be delayed because of a number of reason: - Block allocation for files - Data writebacks for direct I/O - Sleeping because of waiting to acquire i_rwsem -