linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
* [f2fs-dev] [Bug 213877] New: Mount multiple SMR block devices exceed certain number cause system non-response
@ 2021-07-27 10:07 bugzilla-daemon
  2021-07-27 10:10 ` [f2fs-dev] [Bug 213877] " bugzilla-daemon
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: bugzilla-daemon @ 2021-07-27 10:07 UTC (permalink / raw)
  To: linux-f2fs-devel

https://bugzilla.kernel.org/show_bug.cgi?id=213877

            Bug ID: 213877
           Summary: Mount multiple SMR block devices exceed certain number
                    cause system non-response
           Product: File System
           Version: 2.5
    Kernel Version: Linux DT1 5.13.4-200.fc34.x86_64 #1 SMP Tue Jul 20
                    20:27:29 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
          Hardware: Intel
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: f2fs
          Assignee: filesystem_f2fs@kernel-bugs.kernel.org
          Reporter: leftzheng@gmail.com
        Regression: No

[1.] One-line summary of the problem:
Mount multiple SMR block devices exceed certain number cause system
non-response

[2.] Full description of the problem/report:
Created some F2FS on SMR devices (mkfs.f2fs -m), then mounted in sequence. Each
device is the same Model: HGST HSH721414AL (Size 14TB).
Empirically, found that when the amount of SMR device * 1.5Gb > System RAM, the
system ran out of memory and hung. No dmesg output. For example, 24 SMR Disk
need 24*1.5GB = 36GB. A system with 32G RAM can only mount 21 devices, the 22nd
device will be a reproducible cause of system hang.
The number of SMR devices with other FS mounted on this system does not
interfere with the result above.

[3.] Keywords (i.e., modules, networking, kernel):
F2FS, SMR, Memory

[4.] Kernel information
[4.1.] Kernel version (uname -a):
Linux 5.13.4-200.fc34.x86_64 #1 SMP Tue Jul 20 20:27:29 UTC 2021 x86_64 x86_64
x86_64 GNU/Linux

[4.2.] Kernel .config file:
Default Fedora 34 with f2fs-tools-1.14.0-2.fc34.x86_64

[5.] Most recent kernel version which did not have the bug:
None

[6.] Output of Oops.. message (if applicable) with symbolic information
     resolved (see Documentation/admin-guide/oops-tracing.rst)
None

[7.] A small shell script or example program which triggers the
     problem (if possible)
mount /dev/sdX /mnt/0X

[8.] Memory consumption 

With 24 * 14T SMR Block device with F2FS
free -g
              total        used        free      shared  buff/cache   available
Mem:             46          36           0           0          10          10
Swap:             0           0           0


With 3 * 14T SMR Block device with F2FS
free -g
               total        used        free      shared  buff/cache  
available
Mem:               7           5           0           0           1          
1
Swap:              7           0           7

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-04 11:43 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-27 10:07 [f2fs-dev] [Bug 213877] New: Mount multiple SMR block devices exceed certain number cause system non-response bugzilla-daemon
2021-07-27 10:10 ` [f2fs-dev] [Bug 213877] " bugzilla-daemon
2021-07-27 16:22 ` bugzilla-daemon
2021-07-30  3:10 ` bugzilla-daemon
2021-07-30  3:26 ` bugzilla-daemon
2021-07-30 10:04 ` bugzilla-daemon
2021-09-04 10:17 ` bugzilla-daemon
2021-09-04 11:43 ` bugzilla-daemon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).