On 2021/3/19 下午11:34, Dāvis Mosāns wrote:
ceturtd., 2021. g. 18. marts, plkst. 01:49 — lietotājs Qu Wenruo
() rakstīja:
On 2021/3/18 上午5:03, Dāvis Mosāns wrote:
trešd., 2021. g. 17. marts, plkst. 12:28 — lietotājs Qu Wenruo
() rakstīja:
On 2021/3/17 上午9:29, Dāvis Mosāns wrote:
trešd
On 2021/3/18 上午5:03, Dāvis Mosāns wrote:
trešd., 2021. g. 17. marts, plkst. 12:28 — lietotājs Qu Wenruo
() rakstīja:
On 2021/3/17 上午9:29, Dāvis Mosāns wrote:
trešd., 2021. g. 17. marts, plkst. 03:18 — lietotājs Dāvis Mosāns
() rakstīja:
Currently if there's any corruption at all
On 2021/3/17 上午9:29, Dāvis Mosāns wrote:
trešd., 2021. g. 17. marts, plkst. 03:18 — lietotājs Dāvis Mosāns
() rakstīja:
Currently if there's any corruption at all in extent tree
(eg. even single bit) then mounting will fail with:
"failed to read block groups: -5" (-EIO)
It happens because
rl:
https://github.com/0day-ci/linux/commits/Qu-Wenruo/btrfs-make-btrfs_dirty_inode-to-always-reserve-metadata-space/20210108-134133
base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next
in testcase: stress-ng
on test machine: 96 threads Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 51
On 2020/11/26 下午4:56, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: ccb0edc68b690d0a62e9377ab509eb2f7cb610d3 ("btrfs: stop running all
> delayed refs during snapshot")
>
On 2020/11/23 下午2:47, Jan Kiszka wrote:
> On 22.11.20 17:35, Michał Mirosław wrote:
>> On Sun, Nov 22, 2020 at 03:43:33PM +0100, Jan Kiszka wrote:
>>> On 09.11.20 00:28, Qu Wenruo wrote:
>>>> On 2020/11/9 上午1:18, Michał Mirosław wrote:
>>>>> On Sun
On 2020/11/11 下午9:38, Pavel Machek wrote:
> Hi!
>
>>>> From: Qu Wenruo
>>>>
>>>> commit 496245cac57e26d8b738d85c7a29cf9a47610f3f upstream.
>>>>
>>>> There is a report in kernel bugzilla about mismatch file type in dir
>&g
On 2020/11/11 下午9:13, Pavel Machek wrote:
> Hi!
>
>> From: Qu Wenruo
>>
>> commit 496245cac57e26d8b738d85c7a29cf9a47610f3f upstream.
>>
>> There is a report in kernel bugzilla about mismatch file type in dir
>> item and inode item.
>>
>&
On 2020/11/9 上午1:18, Michał Mirosław wrote:
> On Sun, Nov 08, 2020 at 03:35:33PM +0800, Qu Wenruo wrote:
>> Hi Michał,
>>
>> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
>> from NVME.
>>
>> It turns out that, commit aea6cb9
same time, the dmesg shows nothing about the problem, making
debug much harder.
This patch will introduce a macro, rockchip_get_regulator(), which we
can get mandatory or optional regulator with just one line, with proper
error message when it goes wrong.
Signed-off-by: Qu Wenruo
---
d
Also add Rockchip and device tree mail lists to the CC, just in case we
need to update the device tree for RK808.
On 2020/11/8 下午3:35, Qu Wenruo wrote:
> Hi Michał,
>
> Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
> from NVME.
>
> It turn
Hi Michał,
Recently when testing v5.10-rc2, I found my RK3399 boards failed to boot
from NVME.
It turns out that, commit aea6cb99703e ("regulator: resolve supply after
creating regulator") seems to be the cause.
In RK3399 board, vpcie1v8 and vpcie0v9 of the pcie controller is
provided by RK808
Hi guys,
I see your awesome contribution to support Rock Pi 4B.
However in recent rc (v5.10-rc2), I found that even with `vpcie1v8` and
`vpcie0v9` added, `regulartor_dev_lookup()` now just returns
-EPROBE_DEFER, preventing rockchip pcie controller to be initialized.
The full callchain is:
On 2020/11/5 下午5:13, Heiner Kallweit wrote:
> On 05.11.2020 08:42, Qu Wenruo wrote:
>>
>>
>> On 2020/11/5 下午3:01, Heiner Kallweit wrote:
>>> On 05.11.2020 03:48, Qu Wenruo wrote:
>>>> Hi,
>>>>
>>>> Not sure if this is a regre
On 2020/11/5 下午3:01, Heiner Kallweit wrote:
> On 05.11.2020 03:48, Qu Wenruo wrote:
>> Hi,
>>
>> Not sure if this is a regression or not, but just find out that after
>> upgrading to v5.9 kernel, one of my ethernet port on my ThinkPad T14 (ryzen
>> version) b
Hi,
Not sure if this is a regression or not, but just find out that after upgrading
to v5.9 kernel, one of my ethernet port on my ThinkPad T14 (ryzen version)
becomes very slow.
Only *2~3* Mbps.
The laptop has two ethernet interfaces, one needs a passive adapter, the other
one is a standard
Hi,
Recently I tried to run v5.10-rc2 kernel on my RK3399 board (Rock Pi 4B,
4G ram version), most drivers work, but the PCIE RC of the board fails
to register, without obvious dmesg error.
My previous v5.9 kernel runs pretty fine on that board, and can boot
from root on LVM on NVME device
On 2020/11/3 下午5:47, Geert Uytterhoeven wrote:
> On Tue, Nov 3, 2020 at 10:43 AM Naresh Kamboju
> wrote:
>> Linux next 20201103 tag make modules failed for i386 and arm
>> architecture builds.
>>
>> Error log:
>> LD [M] fs/btrfs/btrfs.o
>> MODPOST Module.symvers
>> ERROR: modpost:
On 2020/9/16 上午11:32, Oliver Sang wrote:
> On Tue, Sep 15, 2020 at 04:00:40PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2020/9/15 下午3:40, Qu Wenruo wrote:
>>>
>>>
>>> On 2020/9/15 下午1:54, Oliver Sang wrote:
>>>> On Wed, Sep 09, 2020 at 03:4
On 2020/9/15 下午3:40, Qu Wenruo wrote:
>
>
> On 2020/9/15 下午1:54, Oliver Sang wrote:
>> On Wed, Sep 09, 2020 at 03:49:30PM +0800, Qu Wenruo wrote:
>>>
>>>
>>> On 2020/9/9 下午3:08, kernel test robot wrote:
>>>> Greeting,
>>&g
On 2020/9/15 下午1:54, Oliver Sang wrote:
> On Wed, Sep 09, 2020 at 03:49:30PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2020/9/9 下午3:08, kernel test robot wrote:
>>> Greeting,
>>>
>>> FYI, we noticed the following commit (built with gcc-9):
>>
tions")
> url:
> https://github.com/0day-ci/linux/commits/Qu-Wenruo/btrfs-Enhanced-runtime-defence-against-fuzzed-images/20200809-201720
> base: https://git.kernel.org/cgit/linux/kernel/git/kdave/linux.git for-next
>
> in testcase: fio-basic
> with following parameters:
>
&g
extra info.
So this patch will add extra error messages for -ENOEXEC and -EPERM
errors, allowing user to do better debugging and reporting.
Signed-off-by: Qu Wenruo
Reviewed-by: Lucas De Marchi
---
Changelog:
v2:
- Add extra section description for the error message of
module_enforce_rw
get extra info.
So this patch will add extra error messages for -ENOEXEC and -EPERM
errors, allowing user to do better debugging and reporting.
Signed-off-by: Qu Wenruo
---
kernel/module.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/kernel/module.c b/kernel/modu
get extra info.
So this patch will add extra error messages for -ENOEXEC and -EPERM
errors, allowing user to do better debugging and reporting.
Signed-off-by: Qu Wenruo
---
kernel/module.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/kernel/module.c b/kernel/modu
block
> group item")
> CC: sta...@vger.kernel.org # 5.8+
> Signed-off-by: Marcos Paulo de Souza
Reviewed-by: Qu Wenruo
It would be even nicer if you could add some warning or self-test on
cache->length to prevent such problem from happening again.
Thanks,
Qu
> ---
> fs/
d2fb4bf9 ("kobject: Avoid premature parent object freeing in
> kobject_cleanup()")
> Reported-by: Qu Wenruo
Sorry, I should use my suse mailbox for that.
> Cc: Heikki Krogerus
> Signed-off-by: Andy Shevchenko
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> v2: replaced
On 2020/8/3 下午3:27, Andy Shevchenko wrote:
> On Mon, Aug 3, 2020 at 10:25 AM Andy Shevchenko
> wrote:
>> On Mon, Aug 3, 2020 at 9:47 AM Qu Wenruo wrote:
>>> On 2020/6/5 上午1:46, Rafael J. Wysocki wrote:
>
>>>> +void kobject_del(struct kobject *kobj)
>&
On 2020/6/5 上午1:46, Rafael J. Wysocki wrote:
> From: Heikki Krogerus
>
> If kobject_del() is invoked by kobject_cleanup() to delete the
> target kobject, it may cause its parent kobject to be freed
> before invoking the target kobject's ->release() method, which
> effectively means freeing the
On 2020/5/1 上午9:05, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 1 May 2020 10:24:53 +1000 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the btrfs tree got a conflict in:
>>
>> fs/btrfs/transaction.c
>>
>> between commit:
>>
>> fcc99734d1d4 ("btrfs: transaction: Avoid
backref, don't add refs from shared block when
> resolving normal backref")
OK, at least this fix is mentioning it's older gcc causing problem, and
the fix using GNU extension is also clear.
Reviewed-by: Qu Wenruo
Thanks,
Qu
> Signed-off-by: Arnd Bergmann
> ---
> fs/btrfs/backref.c |
east print fsid correctly:
0.000 xfs_io/79619
btrfs:qgroup_meta_reserve:23ad1511-dd83-47d4-a79c-e96625a15a6e
refroot=5(FS_TREE) type=0x0 diff=2
Signed-off-by: Qu Wenruo
---
Changelog:
v2:
- Use more comment explaining the finetunings we skipped for %pU*
- Extra check for the field before readin
east print fsid correctly:
0.000 xfs_io/79619
btrfs:qgroup_meta_reserve:23ad1511-dd83-47d4-a79c-e96625a15a6e
refroot=5(FS_TREE) type=0x0 diff=2
Signed-off-by: Qu Wenruo
---
Please note in above case, the @type and @diff are not properly showed.
That's another problem, will be addressed in lat
[...]
>>> I have made a simple fuzzer to inject messy in inode metadata,
>>> dir data, compressed indexes and super block,
>>> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?h=experimental-fuzzer
>>>
>>> I am testing with some given dirs and the following script.
>>>
On 2019/6/14 下午7:51, Young Xiao wrote:
> There is a corner case that slips through the checkers in functions
> reading extent buffer, ie.
>
> if (start < eb->len) and (start + len > eb->len), then:
> the checkers in read_extent_buffer_to_user(), and memcmp_extent_buffer()
> WARN_ON(start >
Hi,
When compiling the kernel on v5.2-rc (both rc1 and rc2) with "make
-j12", the gcc will randomly crash with segfault, while on v5.1-rc7
everything is OK.
The crash only happens when the VM has only 1G ram, when given 4G ram it
no longer crash.
However according to dmesg, there is no OOM
On 2019/5/10 上午11:19, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: ddf30cf03fb53b9a0ad0f355a69dbedf416edde9 ("btrfs: extent-tree: Use
> btrfs_ref to refactor add_pinned_bytes()")
>
On 2019/4/2 上午11:14, Rong Chen wrote:
>
> On 4/1/19 11:40 PM, David Sterba wrote:
>> On Mon, Apr 01, 2019 at 11:02:37PM +0800, Chen, Rong A wrote:
>>> On 4/1/2019 10:29 PM, Qu Wenruo wrote:
>>>> On 2019/4/1 下午10:02, Chen, Rong A wrote:
>>>>
On 2019/4/2 上午11:14, Rong Chen wrote:
>
> On 4/1/19 11:40 PM, David Sterba wrote:
>> On Mon, Apr 01, 2019 at 11:02:37PM +0800, Chen, Rong A wrote:
>>> On 4/1/2019 10:29 PM, Qu Wenruo wrote:
>>>> On 2019/4/1 下午10:02, Chen, Rong A wrote:
>>>>
On 2019/4/1 下午10:02, Chen, Rong A wrote:
>
> On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
>>
>> On 1.04.19 г. 16:24 ч., kernel test robot wrote:
>>> FYI, we noticed the following commit (built with gcc-7):
>>>
>>> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
>>> tree-checker:
On 2019/3/12 下午9:50, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -15.1% regression of aim7.jobs-per-min due to commit:
>
>
> commit: 44fe89de7d5157a4f31f13d94802c7619e23f462 ("btrfs: Do mandatory tree
> block check before submitting bio")
That commit will cause extra check
ldn't want to pass negatives to read_extent_buffer(). Also there
> is an extra cast.
>
> This patch shouldn't affect runtime, it's just a clean up.
>
> Suggested-by: Dan Carpenter
> Signed-off-by: YueHaibing
Reviewed-by: Qu Wenruo
The commit message is much better.
Thanks,
Qu
>
On 2019/2/20 上午11:08, YueHaibing wrote:
> btrfs_item_size_nr return value is u32, convert it to int may result
> in truncation.Also read_extent_buffer expect a unsigned param, so
> min_t should use type u32 to compare.
Btrfs has a up limit on item size, it will never exceed 64K - various
On 2019/1/11 下午10:03, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 05a37c48604c19b50873fd9663f9140c150469d1 ("btrfs: volumes: Make sure
> no dev extent is beyond device boundary")
>
oup);
> ret = sysfs_create_group(fsid_kobj, _feature_attr_group);
> + if (ret)
> + btrfs_err(fs_info, "failed to create
> btrfs_feature_attr_group.\n");
Forgot to mention, for btrfs_* infrastructure, no need for the ending '\n'.
Despite that, looks good.
Reviewed
On 2018/12/26 上午11:46, Kangjie Lu wrote:
> In case sysfs_create_group fails, let's check its return value and
> issues an error message.
>
> Signed-off-by: Kangjie Lu
> ---
> fs/btrfs/sysfs.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
>
Hi,
When testing IO heavy work on my VM backed by Ryzen 1700 CPU, I turned
to brd modules, but surprisingly, the speed is even slower than some HDD:
---
$ sudo modprobe brd rd_nr=1 rd_size=1048576
$ dd if=/dev/zero of=/dev/ram0 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824
Hi,
When testing IO heavy work on my VM backed by Ryzen 1700 CPU, I turned
to brd modules, but surprisingly, the speed is even slower than some HDD:
---
$ sudo modprobe brd rd_nr=1 rd_size=1048576
$ dd if=/dev/zero of=/dev/ram0 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824
The latest patch handles it by introducing new @super_num parameter and
different check timing.
Thanks,
Qu
On 2018年04月23日 09:20, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 7eafb77890ff459863e3bc772465cb641c14f754 ("btrfs: Do super block
>
The latest patch handles it by introducing new @super_num parameter and
different check timing.
Thanks,
Qu
On 2018年04月23日 09:20, kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 7eafb77890ff459863e3bc772465cb641c14f754 ("btrfs: Do super block
>
On 2017年12月22日 00:49, David Sterba wrote:
> On Wed, Dec 20, 2017 at 08:12:11AM +0800, Qu Wenruo wrote:
>> On 2017年12月20日 06:20, Stephen Rothwell wrote:
>>> After merging the btrfs-kdave tree, today's linux-next build (powerpc
>>> ppc64_defconfig) produced this warning
On 2017年12月22日 00:49, David Sterba wrote:
> On Wed, Dec 20, 2017 at 08:12:11AM +0800, Qu Wenruo wrote:
>> On 2017年12月20日 06:20, Stephen Rothwell wrote:
>>> After merging the btrfs-kdave tree, today's linux-next build (powerpc
>>> ppc64_defconfig) produced this warning
On 2017年12月20日 06:20, Stephen Rothwell wrote:
> Hi David,
>
> After merging the btrfs-kdave tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/btrfs/qgroup.c: In function 'qgroup_reserve':
> fs/btrfs/qgroup.c:2432:1: warning: label 'retry' defined but not
On 2017年12月20日 06:20, Stephen Rothwell wrote:
> Hi David,
>
> After merging the btrfs-kdave tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/btrfs/qgroup.c: In function 'qgroup_reserve':
> fs/btrfs/qgroup.c:2432:1: warning: label 'retry' defined but not
87f2e3e0 ("btrfs: tree-checker: Add checker for dir item")
Reviewed-by: Qu Wenruo <w...@suse.com>
Thanks,
Qu
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> fs/btrfs/tree-checker.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
87f2e3e0 ("btrfs: tree-checker: Add checker for dir item")
Reviewed-by: Qu Wenruo
Thanks,
Qu
> Signed-off-by: Arnd Bergmann
> ---
> fs/btrfs/tree-checker.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/tree-checker.c b/fs/btrf
used parameters from various functions
> btrfs: Remove unused arguments from btrfs_changed_cb_t
> btrfs: Remove unused parameter from check_direct_IO
> btrfs: Rework error handling of add_extent_mapping in
> __btrfs_alloc_chunk
> btrfs: Remove redundan
used parameters from various functions
> btrfs: Remove unused arguments from btrfs_changed_cb_t
> btrfs: Remove unused parameter from check_direct_IO
> btrfs: Rework error handling of add_extent_mapping in
> __btrfs_alloc_chunk
> btrfs: Remove redundan
On 2017年09月10日 19:19, Christophe JAILLET wrote:
If 'btrfs_alloc_path()' fails, we must free the resourses already
allocated, as done in the other error handling paths in this function.
Signed-off-by: Christophe JAILLET <christophe.jail...@wanadoo.fr>
Reviewed-by: Qu Wenruo <qu
On 2017年09月10日 19:19, Christophe JAILLET wrote:
If 'btrfs_alloc_path()' fails, we must free the resourses already
allocated, as done in the other error handling paths in this function.
Signed-off-by: Christophe JAILLET
Reviewed-by: Qu Wenruo
BTW, I also checked all btrfs_alloc_path
At 03/07/2017 03:41 PM, Reshetova, Elena wrote:
At 03/06/2017 05:43 PM, Reshetova, Elena wrote:
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
At 03/07/2017 03:41 PM, Reshetova, Elena wrote:
At 03/06/2017 05:43 PM, Reshetova, Elena wrote:
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
At 03/06/2017 05:43 PM, Reshetova, Elena wrote:
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
At 03/06/2017 05:43 PM, Reshetova, Elena wrote:
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
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
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
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
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
At 12/21/2016 04:28 PM, Sebastian Andrzej Siewior wrote:
On 2016-12-21 08:33:03 [+0800], Qu Wenruo wrote:
The trace point only uses the pointer, and this helps us to pair with
btrfs_work_queued/sched.
| /* For situiations that the work is freed */
| DECLARE_EVENT_CLASS(btrfs__work__done
At 12/21/2016 04:28 PM, Sebastian Andrzej Siewior wrote:
On 2016-12-21 08:33:03 [+0800], Qu Wenruo wrote:
The trace point only uses the pointer, and this helps us to pair with
btrfs_work_queued/sched.
| /* For situiations that the work is freed */
| DECLARE_EVENT_CLASS(btrfs__work__done
At 12/21/2016 01:26 AM, David Sterba wrote:
Adding Qu to CC,
On Wed, Dec 14, 2016 at 03:05:29PM +0100, Sebastian Andrzej Siewior wrote:
For btrfs_scrubparity_helper() the ->func() is set to
scrub_parity_bio_endio_worker(). This functions invokes
scrub_free_parity() which kfrees() the `work'
At 12/21/2016 01:26 AM, David Sterba wrote:
Adding Qu to CC,
On Wed, Dec 14, 2016 at 03:05:29PM +0100, Sebastian Andrzej Siewior wrote:
For btrfs_scrubparity_helper() the ->func() is set to
scrub_parity_bio_endio_worker(). This functions invokes
scrub_free_parity() which kfrees() the `work'
At 11/10/2016 06:57 AM, Andreas Dilger wrote:
On Nov 9, 2016, at 1:56 PM, Jaegeuk Kim wrote:
This patch implements multiple devices support for f2fs.
Given multiple devices by mkfs.f2fs, f2fs shows them entirely as one big
volume under one f2fs instance.
Internal block
At 11/10/2016 06:57 AM, Andreas Dilger wrote:
On Nov 9, 2016, at 1:56 PM, Jaegeuk Kim wrote:
This patch implements multiple devices support for f2fs.
Given multiple devices by mkfs.f2fs, f2fs shows them entirely as one big
volume under one f2fs instance.
Internal block management is very
At 09/05/2016 09:19 AM, Zhao Lei wrote:
> Hi, Sean Fu
>
>> From: Sean Fu [mailto:fxinr...@gmail.com]
>> Sent: Sunday, September 04, 2016 7:54 PM
>> To: dste...@suse.com
>> Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com;
>> zhao...@cn.fujitsu.com; linux-bt...@vger.kernel.org;
>>
At 09/05/2016 09:19 AM, Zhao Lei wrote:
> Hi, Sean Fu
>
>> From: Sean Fu [mailto:fxinr...@gmail.com]
>> Sent: Sunday, September 04, 2016 7:54 PM
>> To: dste...@suse.com
>> Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com;
>> zhao...@cn.fujitsu.com; linux-bt...@vger.kernel.org;
>>
At 09/07/2016 09:38 AM, Sean Fu wrote:
On Mon, Sep 05, 2016 at 03:56:41PM +0800, Qu Wenruo wrote:
At 09/05/2016 09:19 AM, Zhao Lei wrote:
Hi, Sean Fu
From: Sean Fu [mailto:fxinr...@gmail.com]
Sent: Sunday, September 04, 2016 7:54 PM
To: dste...@suse.com
Cc: c...@fb.com; anand.j
At 09/07/2016 09:38 AM, Sean Fu wrote:
On Mon, Sep 05, 2016 at 03:56:41PM +0800, Qu Wenruo wrote:
At 09/05/2016 09:19 AM, Zhao Lei wrote:
Hi, Sean Fu
From: Sean Fu [mailto:fxinr...@gmail.com]
Sent: Sunday, September 04, 2016 7:54 PM
To: dste...@suse.com
Cc: c...@fb.com; anand.j
At 09/05/2016 09:19 AM, Zhao Lei wrote:
Hi, Sean Fu
From: Sean Fu [mailto:fxinr...@gmail.com]
Sent: Sunday, September 04, 2016 7:54 PM
To: dste...@suse.com
Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com;
zhao...@cn.fujitsu.com; linux-bt...@vger.kernel.org;
At 09/05/2016 09:19 AM, Zhao Lei wrote:
Hi, Sean Fu
From: Sean Fu [mailto:fxinr...@gmail.com]
Sent: Sunday, September 04, 2016 7:54 PM
To: dste...@suse.com
Cc: c...@fb.com; anand.j...@oracle.com; fdman...@suse.com;
zhao...@cn.fujitsu.com; linux-bt...@vger.kernel.org;
Chris Mason wrote on 2016/01/21 12:06 -0500:
On Thu, Jan 14, 2016 at 10:07:31PM -0500, Dave Jones wrote:
I just hit a bunch of instances of this spew..
This is on Linus' tree from a few hours ago
==
BUG: KASAN: use-after-free in
Chris Mason wrote on 2016/01/21 12:06 -0500:
On Thu, Jan 14, 2016 at 10:07:31PM -0500, Dave Jones wrote:
I just hit a bunch of instances of this spew..
This is on Linus' tree from a few hours ago
==
BUG: KASAN: use-after-free in
David Sterba wrote on 2015/12/30 17:17 +0100:
On Wed, Dec 30, 2015 at 10:10:44PM +0800, Qu Wenruo wrote:
Now I am on the same side of David.
Which means a runtime interface to change them. (along with mkfs option)
If provide some configurable features, then it should be able to be
tuned
On 12/30/2015 05:54 PM, Sanidhya Solanki wrote:
On Wed, 30 Dec 2015 19:59:16 +0800
Qu Wenruo wrote:
Not really sure about the difference between 2 and 3.
I should have made it clear before, I was asking the exact use case in
mind when listing the choices. Option 2 would be for SysAdmins
On 12/30/2015 02:39 PM, Sanidhya Solanki wrote:
On Tue, 29 Dec 2015 18:06:11 +0100
David Sterba wrote:
So you want to make the stripe size configurable?...
As I see it there are 3 ways to do it:
-Make it a compile time option that only configures it for a single
system with any devices
David Sterba wrote on 2015/12/30 17:17 +0100:
On Wed, Dec 30, 2015 at 10:10:44PM +0800, Qu Wenruo wrote:
Now I am on the same side of David.
Which means a runtime interface to change them. (along with mkfs option)
If provide some configurable features, then it should be able to be
tuned
On 12/30/2015 05:54 PM, Sanidhya Solanki wrote:
On Wed, 30 Dec 2015 19:59:16 +0800
Qu Wenruo <quwenruo.bt...@gmx.com> wrote:
Not really sure about the difference between 2 and 3.
I should have made it clear before, I was asking the exact use case in
mind when listing the choices. Op
On 12/30/2015 02:39 PM, Sanidhya Solanki wrote:
On Tue, 29 Dec 2015 18:06:11 +0100
David Sterba wrote:
So you want to make the stripe size configurable?...
As I see it there are 3 ways to do it:
-Make it a compile time option that only configures it for a single
system
Alexandru Moise wrote on 2015/08/31 09:32 +0300:
On Mon, Aug 31, 2015 at 09:44:49AM +0800, Qu Wenruo wrote:
>From the perspective of users, qgroup's referenced or exclusive
is negative,but user can not continue to write data! a workaround
way is to cast u64 to s64 when do
Alexandru Moise wrote on 2015/08/31 09:32 +0300:
On Mon, Aug 31, 2015 at 09:44:49AM +0800, Qu Wenruo wrote:
>From the perspective of users, qgroup's referenced or exclusive
is negative,but user can not continue to write data! a workaround
way is to cast u64 to s64 when do
Alexandru Moise wrote on 2015/08/29 11:45 +:
This patch reverts commit: b4fcd6be6bbd702ae1a6545c9b413681850a9814
Wang Shilong added those casts as a workaround for a bug reproduced
using the following steps:
Steps to reproduce:
mkfs.btrfs
mount
dd if=/dev/zero
Alexandru Moise wrote on 2015/08/29 11:45 +:
This patch reverts commit: b4fcd6be6bbd702ae1a6545c9b413681850a9814
Wang Shilong added those casts as a workaround for a bug reproduced
using the following steps:
Steps to reproduce:
mkfs.btrfs disk
mount disk mnt
dd
Original Message
Subject: Re: [PATCH v2 0/6] Btrfs: show subvolume name and ID in
/proc/mounts
From: Omar Sandoval
To: David Sterba , Qu Wenruo ,
Date: 2015年05月11日 17:42
On Thu, Apr 09, 2015 at 02:34:50PM -0700, Omar Sandoval wrote:
Here's version 2 of providing
Original Message
Subject: Re: [PATCH v2 0/6] Btrfs: show subvolume name and ID in
/proc/mounts
From: Omar Sandoval osan...@osandov.com
To: David Sterba dste...@suse.cz, Qu Wenruo quwen...@cn.fujitsu.com,
linux-bt...@vger.kernel.org
Date: 2015年05月11日 17:42
On Thu, Apr 09
Original Message
Subject: Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
From: Omar Sandoval
To: Qu Wenruo
Date: 2015年04月08日 15:17
On Wed, Apr 08, 2015 at 02:06:14PM +0800, Qu Wenruo wrote:
Original Message
Subject: [PATCH 2/3] Btrfs
Original Message
Subject: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
From: Omar Sandoval
To: Chris Mason , Josef Bacik , David Sterba
,
Date: 2015年04月08日 13:34
Currently, mounting a subvolume with subvolid= takes a different code
path than mounting with
Original Message
Subject: [PATCH 3/3] Btrfs: show subvol= and subvolid= in /proc/mounts
From: Omar Sandoval
To: Chris Mason , Josef Bacik , David Sterba
,
Date: 2015年04月08日 13:34
Currently, userspace has no way to know which subvolume is mounted.But,
now that we're
Original Message
Subject: [PATCH 3/3] Btrfs: show subvol= and subvolid= in /proc/mounts
From: Omar Sandoval osan...@osandov.com
To: Chris Mason c...@fb.com, Josef Bacik jba...@fb.com, David Sterba
dste...@suse.cz, linux-bt...@vger.kernel.org
Date: 2015年04月08日 13:34
Original Message
Subject: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
From: Omar Sandoval osan...@osandov.com
To: Chris Mason c...@fb.com, Josef Bacik jba...@fb.com, David Sterba
dste...@suse.cz, linux-bt...@vger.kernel.org
Date: 2015年04月08日 13:34
Currently,
Original Message
Subject: Re: [PATCH 2/3] Btrfs: unify subvol= and subvolid= mounting
From: Omar Sandoval osan...@osandov.com
To: Qu Wenruo quwen...@cn.fujitsu.com
Date: 2015年04月08日 15:17
On Wed, Apr 08, 2015 at 02:06:14PM +0800, Qu Wenruo wrote:
Original
1 - 100 of 106 matches
Mail list logo