[PATCH] Btrfs-progs: fix infinite loop in find_free_extent

From: Liu Bo %search_start is calculated in a wrong way, and if %ins is a cross-stripe one, it'll search the same block group forever. Signed-off-by: Liu Bo --- extent-tree.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff

linrong★SEMA SHOW★ 2017第49届美国拉斯维加斯国际汽车改装及配件用品展 —— 全球规模最大汽车制造业展会 [地右P4/L100-Z]

linrong 　　 尊敬的 企业领导/公司负责人/业界专家，您好： 　　 　　现将“全球规模最大的、历史最悠久、最著名的汽车制造业贸易及汽车售后服务市场专业展会”「SEMA SHOW 2017 & AAPEX SHOW 2017」资讯发送给您。 　　请积极参与、共享盛会； 提前安排、赢得先机 —— 　　 SEMA SHOW 2017 & AAPEX SHOW 2017 2017第49届美国拉斯维加斯国际汽车改装及配件用品展览会 　　 　　 １、 基 本 信 息 ： 　　 展会名称： 2017第49届美国拉斯维加斯国际汽车改装及用品展览会 （SEMA SHOW

Re: How to fix errors that check --mode lomem finds, but --mode normal doesn't?

On Fri, Jun 23, 2017 at 09:17:50AM -0700, Marc MERLIN wrote: > Thanks for looking at this. > I have applied your patch and I'm still re-running check in lowmem. It takes > about 24H so I'll > post the full results when it's done. Ok, here is the output of the check with btrfs-progs freshly

Re: Exactly what is wrong with RAID5/6

On 2017-06-23 13:25, Michał Sokołowski wrote: Hello group. I am confused: Can somebody please confirm/deny, which RAID subsystem is affected? BTRFS' RAID5/6 or mdadm (Linux kernel raid) RAID 5/6 ? All of the issues mentioned here are specific to BTRFS raid5/raid6 profiles, with the exception

Re: [PATCH v2] btrfs: fix integer overflow in calc_reclaim_items_nr

On Fri, Jun 23, 2017 at 09:48:21AM -0700, Chris Mason wrote: > Dave Jones hit a WARN_ON(nr < 0) in btrfs_wait_ordered_roots() with > v4.12-rc6. This was because commit 70e7af244 made it possible for > calc_reclaim_items_nr() to return a negative number. It's not really a > bug in that commit, it

Re: Exactly what is wrong with RAID5/6

Hello group. I am confused: Can somebody please confirm/deny, which RAID subsystem is affected? BTRFS' RAID5/6 or mdadm (Linux kernel raid) RAID 5/6 ? Are there some gotchas (in terms of broken reliability) when using kernel one? The web is full of legends, it seems that this confusion is quite

Re: btrfs fi usage crash when multiple device volume contains seed device

On Fri, Jun 23, 2017 at 3:46 AM, Cengiz C. wrote: > Hello Chris, > > Sorry, I'm a newbie on LKML flow, I didn't copy you while replying. > > If you have any spare time to talk about this issue, I'd be extremely happy. > > Thanks again > > On Sun, Jun 18, 2017 at 10:12 PM,

Re: [PATCH v2 0/4] Qgroup uapi improvements

On Fri, May 26, 2017 at 1:44 PM, Sargun Dhillon wrote: > This patchset has several improvements around the qgroups user-facing > API. It introduces two new ioctls for creating, and removing qgroups. > These ioctls have a new args structure that allows passing flags, and > some

[PULL] Btrfs for 4.13, part 1

Hi, this is the main batch for 4.13. There are some user visible changes, see below. The core updates improve error handling (mostly related to bios), with the usual incremental work on the GFP_NOFS (mis)use removal. All patches have been in for-next for an extensive amount of time. Thre will be

Re: [PATCH] btrfs: fix integer overflow in calc_reclaim_items_nr

On Fri, Jun 23, 2017 at 05:29:56PM +0200, Holger Hoffstätte wrote: > On 06/23/17 16:32, Chris Mason wrote: > [..] > > -static inline int calc_reclaim_items_nr(struct btrfs_fs_info *fs_info, > > +static inline u64 calc_reclaim_items_nr(struct btrfs_fs_info *fs_info, > >

Re: [RFC PATCH 0/4] Support for metadata specific accounting

On Thu, Jun 22, 2017 at 11:08:49AM -0400, Josef Bacik wrote: > On Thu, Jun 22, 2017 at 05:23:20PM +0300, Nikolay Borisov wrote: > > This series is a report of Josef's original posting [1]. I've included > > fine-grained changelog in each patch with my changes. Basically, I've > > forward > >

[PATCH v2] btrfs: fix integer overflow in calc_reclaim_items_nr

Dave Jones hit a WARN_ON(nr < 0) in btrfs_wait_ordered_roots() with v4.12-rc6. This was because commit 70e7af244 made it possible for calc_reclaim_items_nr() to return a negative number. It's not really a bug in that commit, it just didn't go far enough down the stack to find all the possible

Re: [PATCH] btrfs: fix integer overflow in calc_reclaim_items_nr

On 06/23/2017 11:29 AM, Holger Hoffstätte wrote: On 06/23/17 16:32, Chris Mason wrote: [..] -static inline int calc_reclaim_items_nr(struct btrfs_fs_info *fs_info, +static inline u64 calc_reclaim_items_nr(struct btrfs_fs_info *fs_info, u64 to_reclaim)

Re: How to fix errors that check --mode lomem finds, but --mode normal doesn't?

On Fri, Jun 23, 2017 at 04:54:01PM +0800, Lu Fengqi wrote: > On 2017年06月23日 12:06, Marc MERLIN wrote: > > > Well, there is only the output from extent tree. > > > > > > I was also expecting output from subvolue (11930) tree. > > > > > > It could be done by > > > # btrfs-debug-tree -t 11930 |

Re: [PATCH] btrfs: fix integer overflow in calc_reclaim_items_nr

On 06/23/17 16:32, Chris Mason wrote: [..] > -static inline int calc_reclaim_items_nr(struct btrfs_fs_info *fs_info, > +static inline u64 calc_reclaim_items_nr(struct btrfs_fs_info *fs_info, > u64 to_reclaim) > { > u64 bytes; > - int nr; > + u64

[PATCH] btrfs: fix integer overflow in calc_reclaim_items_nr

Dave Jones hit a WARN_ON(nr < 0) in btrfs_wait_ordered_roots() with v4.12-rc6. This was because commit 70e7af244 made it possible for calc_reclaim_items_nr() to return a negative number. It's not really a bug in that commit, it just didn't go far enough down the stack to find all the possible

Re: btrfs fi usage crash when multiple device volume contains seed device

Hello Chris, Sorry, I'm a newbie on LKML flow, I didn't copy you while replying. If you have any spare time to talk about this issue, I'd be extremely happy. Thanks again On Sun, Jun 18, 2017 at 10:12 PM, Cengiz Can wrote: > Hello, > > How should we proceed on this? > > I

Re: How to fix errors that check --mode lomem finds, but --mode normal doesn't?

On 2017年06月23日 12:06, Marc MERLIN wrote: Well, there is only the output from extent tree. I was also expecting output from subvolue (11930) tree. It could be done by # btrfs-debug-tree -t 11930 | grep -C 10 3886187384832 I apologize if this was not made clear. But please pay attention

Re: [PATCH v2] btrfs/146: Test various btrfs operations rounding behavior

On Wed, Jun 21, 2017 at 10:50:35AM +0300, Nikolay Borisov wrote: > When changing the size of disks/filesystem we should always be > rounding down to a multiple of sectorsize > > Signed-off-by: Nikolay Borisov Thanks for the update! But I still need some reviews from btrfs