Hi Timofey,
[auto build test ERROR on next-20170724]
[cannot apply to btrfs/next v4.13-rc2 v4.13-rc1 v4.12 v4.13-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Timofey-Titovets/Btrfs-popula
On Sat, Jul 29, 2017 at 12:48:04AM +, Josef Bacik wrote:
> On Fri, Jul 28, 2017 at 09:26:29PM -0300, Ernesto A. Fernández wrote:
> > + ret = __btrfs_set_acl(trans, inode, acl, type);
> > + if (ret)
> > + goto out;
> > +
> > + inode->i_mode = mode;
> > + inode_inc_iversion(inod
webmaster【通过本邮件参展优惠500元一展位，需回信专用邮箱“12809...@qq.com”报名】
尊敬的 企业领导/公司负责人：
诚邀参加中国最大汽配外贸展 —— APF 2017
汽配行业品牌盛会，外贸企业最佳选择，全球采购首选平台！
★ 与“广交会”同期同地举行，
★ 以“广交会”庞大的客流量为依托，买家互动，借势兴展，
★ 共享来自全球数十万采购商资源•••
【 基 本 信 息 】
中文名称： 2017广州国际进出口汽车配件展览会
英文名称： The Guangzhou International Import and E
The read-only scrub finished without errors/hangs (with kernel
4.12.3). So, I guess the hangs were caused by:
1: other bug in 4.13-RC1
2: crazy-random SATA/disk-controller issue
3: interference between various btrfs tools [*]
4: something in the background did DIO write with 4.13-RC1 (but all
affec
On Fri, Jul 28, 2017 at 09:26:29PM -0300, Ernesto A. Fernández wrote:
> When changing a file's acl mask, btrfs_set_acl() will first set the
> group bits of i_mode to the value of the mask, and only then set the
> actual extended attribute representing the new acl.
>
> If the second part fails (due
When changing a file's acl mask, btrfs_set_acl() will first set the
group bits of i_mode to the value of the mask, and only then set the
actual extended attribute representing the new acl.
If the second part fails (due to lack of space, for example) and the
file had no acl attribute to begin with,
On 7/28/2017 9:32 PM, Hermann Schwärzler wrote:
Hi
for me it looks like those snapshots are not read-only. But as far as
I know for using send they have to be.
They are read-only.
# btrfs property get userData.20170727T1222/
ro=true
At least
https://btrfs.wiki.kernel.org/index.php/Increme
On Wed, Jul 12, 2017 at 04:20:10PM -0600, Edmund Nadolski wrote:
> When called with a struct share_check, find_parent_nodes()
> will detect a shared extent and immediately return with
> BACKREF_SHARED_FOUND.
>
Reviewed-by: Liu Bo
Thanks,
-liubo
> Signed-off-by: Edmund Nadolski
> Signed-off-by
Hi
for me it looks like those snapshots are not read-only. But as far as I
know for using send they have to be.
At least
https://btrfs.wiki.kernel.org/index.php/Incremental_Backup#Initial_Bootstrapping
states "We will need to create a read-only snapshot ,,,"
I am using send/receive (with read
On Wed, Jul 12, 2017 at 04:20:06PM -0600, Edmund Nadolski wrote:
> It's been known for a while that the use of multiple lists
> that are periodically merged was an algorithmic problem within
> btrfs. There are several workloads that don't complete in any
> reasonable amount of time (e.g. btrfs/130
In addition to my previous "it does not happen here" comment, if
someone is reading this thread, there are some other interesting
details:
> When the compression is turned off, I am able to get the
> maximum 500-600 mb/s write speed on this disk (raid array)
> with minimal cpu usage.
No details o
On Fri, Jul 28, 2017 at 06:20:14PM +, William Muriithi wrote:
> Hi Roman,
>
> > autodefrag
>
> This sure sounded like a good thing to enable? on paper? right?...
>
> The moment you see anything remotely weird about btrfs, this is the first
> thing you have to disable and retest without. Oh
On Mon, Jul 24, 2017 at 03:14:26PM -0400, jo...@toxicpanda.com wrote:
> From: Josef Bacik
>
> Our dir_context->pos is supposed to hold the next position we're
> supposed to look. If we successfully insert a delayed dir index we
> could end up with a duplicate entry because we don't increase ctx-
On Mon, Jul 24, 2017 at 03:14:25PM -0400, jo...@toxicpanda.com wrote:
> From: Josef Bacik
>
> Readdir does dir_emit while under the btree lock. dir_emit can trigger
> the page fault which means we can deadlock. Fix this by allocating a
> buffer on opening a directory and copying the readdir int
Hi Roman,
> autodefrag
This sure sounded like a good thing to enable? on paper? right?...
The moment you see anything remotely weird about btrfs, this is the first thing
you have to disable and retest without. Oh wait, the first would be qgroups,
this one is second.
What's the problem with au
> I am stuck with a problem of btrfs slow performance when using
> compression. [ ... ]
That to me looks like an issue with speed, not performance, and
in particular with PEBCAK issues.
As to high CPU usage, when you find a way to do both compression
and checksumming without using much CPU time,
On Fri, 28 Jul 2017 17:40:50 +0100 (BST)
"Konstantin V. Gavrilenko" wrote:
> Hello list,
>
> I am stuck with a problem of btrfs slow performance when using compression.
>
> when the compress-force=lzo mount flag is enabled, the performance drops to
> 30-40 mb/s and one of the btrfs processes
I often hit the following error when doing incremental btrfs send-receive:
Btrfs incremental send | receive fails with Error: File not found
Sometimes I can do two-three incremental snapshots, but then the same
error (different file) happens again. It seems that the files were
changed or replac
Hello list,
I am stuck with a problem of btrfs slow performance when using compression.
when the compress-force=lzo mount flag is enabled, the performance drops to
30-40 mb/s and one of the btrfs processes utilises 100% cpu time.
mount options: btrfs
relatime,discard,autodefrag,compress=lzo,co
Hi,
please pull the following btrfs fixes. They're addressing problems reported by
users, and there's one more regression fix. Thanks.
The next pull request will be sent by Chris, I'm heading off to vacation.
The following changes since commit c3cfb656307583ddfea45375c10183737593c195:
Btrfs:
On Mon, Jul 24, 2017 at 03:14:25PM -0400, jo...@toxicpanda.com wrote:
> From: Josef Bacik
>
> Readdir does dir_emit while under the btree lock. dir_emit can trigger
> the page fault which means we can deadlock. Fix this by allocating a
> buffer on opening a directory and copying the readdir int
On 28/07/2017 00:36, David Sterba wrote:
On Mon, Jul 24, 2017 at 11:40:17PM +0800, Anand Jain wrote:
Eg. files that are already compressed would increase the cpu consumption
with compress-force, while they'd be hopefully detected as
incompressible with 'compress' and clever heuristics. So th
On Wed, Jul 12, 2017 at 04:20:05PM -0600, Edmund Nadolski wrote:
> This patch series attempts to improve the performance of backref
> searches by changing the prelim_refs implementation to use
> rbtrees instead of lists. This also aims to reduce the soft
> lockup occurences that can result when a
From: Filipe Manana
When logging an inode in full mode that has an inline compressed extent
that represents a range with a size matching the sector size (currently
the same as the page size), has a trailing hole and the no-holes feature
is enabled, we end up failing an assertion leading to a trac
Hi,
btrfs-progs version 4.12 have been released. Although it's major number update,
there are no major updates, besides the usual bugfixes and enhancements.
Per user request, the tarball now contains the generated manual pages, as the
build dependencies for documentation are not lightweight. If y
On Thu, Jul 27, 2017 at 9:24 PM, Hans van Kranenburg
wrote:
> Device ID numbers always start at 1, not at 0. The first IOC_DEV_INFO
> call does not make sense, since it will always return ENODEV.
When there is a btrfs-replace ongoing, there is a Device ID 0
> ioctl(3, BTRFS_IOC_DEV_INFO, {devid=
btrfs_alloc_dev_extent currently unconditionally sets the uuid in the leaf block
header the function is working with. This is unnecessary since this operation
is peformed by the core btree handling code (splitting a node, allocating a new
btree block etc). So let's remove it.
Signed-off-by: Nikola
On Fri, Jul 28, 2017 at 6:59 AM, Nikolay Borisov wrote:
>
>
> On 27.07.2017 20:57, Filipe Manana wrote:
>> On Thu, Jul 27, 2017 at 6:36 PM, Nikolay Borisov wrote:
>>> Currently btrfs_alloc_dev_extent essentially open codes btrfs_insert_item.
>>> So
>>> let's remove the superfluous code, leaving
28 matches
Mail list logo
