From owner-freebsd-hackers@freebsd.org Thu Apr 16 16:53:11 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0FE1C2C1C6E for ; Thu, 16 Apr 2020 16:53:11 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4934zT6rFKz3H8v for ; Thu, 16 Apr 2020 16:53:09 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03GGr2lX044303 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Apr 2020 16:53:03 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03GGr29B010223 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Apr 2020 23:53:02 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: fsck parallel check To: Wojciech Puchar References: Cc: freebsd-hackers@freebsd.org, Poul-Henning Kamp From: Eugene Grosbein Message-ID: <571d8b81-f4f9-d371-6cf2-2e7aeb82a09b@grosbein.net> Date: Thu, 16 Apr 2020 23:52:52 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4934zT6rFKz3H8v X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; IP_SCORE(-1.89)[ip: (-5.22), ipnet: 2a01:4f8::/29(-2.62), asn: 24940(-1.59), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 16:53:11 -0000 16.04.2020 23:25, Wojciech Puchar wrote: >> Quoting the manual: >> >> In other words: In preen mode all pass 1 partitions are checked >> sequentially. Next all pass 2 partitions are checked in parallel, one >> process per disk drive. Next all pass 3 partitions are checked in >> parallel, one process per disk drive. etc. > > Yes i've read this manual. > > > "Next all pass 2 partitions are checked in parallel, one > process per disk drive." > > so having 5 partitions on one SSD - it will be checked sequentially. Not necessary. Fsck tries to parse device name this way: /path/to/nameNUMBERrest so it skips all chars upto last /, then extracts "name" part not containing any digits, then extracts NUMBER part containing only digits, upto maximum lenght. Then is uses nameNUMBER for "disk name". So if your naming schema is /dev/gpt/gptlabel it all depends on exact label names because /dev/gpt/ part is skipped first. If your gptlabels are in form of nameNUMBERrest where name and NUMBER are all same, fsck threats them as part of single disk and scans sequentially. Otherwise, in parallel. You may easily check it with "fsck -d -p" so it prints verbose details not starting any checks really.