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
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
[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
[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
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
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.
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.
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
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:
%
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
[ ... 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
>> 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'
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
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
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
-
15 matches
Mail list logo