Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp307672pxb; Wed, 22 Sep 2021 23:49:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+9HrewxlqlAOVfCXW1HG2bsXNAJl9835psy6rDsiVzm6cUWUirrtnyKHzEcHpxvPLiL/2 X-Received: by 2002:a6b:5106:: with SMTP id f6mr2511618iob.116.1632379761065; Wed, 22 Sep 2021 23:49:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632379761; cv=none; d=google.com; s=arc-20160816; b=ikKYESRuyU6Dl3r7qEQy8nqTNHOCz9LVnTNtHptegi7KuRacaqiLYnNfGVQjsPyfJi rXDE6bGDJaVXJCZWR4woCTODqdxw/7GckzOlJcvhQtUI0V/4Q2Rl+LDAyHRlCui0NJCL O0c5bc+IHatX9ky7xPkM1NAQeNCC41Ds5Z9RlAI2huyqNMljUMJ3ylVx4VspGQ8tuB9B /LzzI+urYgm3xdV6IaRG8RqsRvtc1l/A0KPS7Ro83YIUzYjxsmB6jItrLsxcUx5rI5ca GGluqMvl3aSjkSbDvLFady+os5RtLfmFYLK0Bte2/2WoyWJCv9vdTK/qGy0Pkvbw1VWK /TfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=rz1C9RFwm0D2b0QJvfZLT5iFFX4aQmKToNhmkBP/7Mw=; b=CzXob+xuMTuiDVjm0/mHJiF7eaWElgM7TOZb7ULERSKusvjCgjQckp06AG9Y66SFLl QtqCYdLtRQR26qf9V/D1TMMO21mTf8Y9YzuZ86X1CpECdI95TEsrzb1cqwY3HdKgkCzR 8FN6pKP6esd7WdC/F6VwRhr4KhSr8wwHfQw378YVBcHYDGjhihk62PLeymfRkYjeSU+k xQ9es6H7xAbP4uMP9rmClBK4Q2fb0mC0d8d8exq/rOk6PfIqUj5McZW+2JIBoauSmgQK Lejoy2GoNCPrGDVpQWJy1ajm5R9ti/Y0adFv8OAH8sAqQfQ17BYgXH1xhqkDGAlRY8kI 3ppA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Qvh3psuo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q15si6291781ilo.78.2021.09.22.23.49.09; Wed, 22 Sep 2021 23:49:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Qvh3psuo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239432AbhIWGt3 (ORCPT + 99 others); Thu, 23 Sep 2021 02:49:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:47756 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239359AbhIWGt2 (ORCPT ); Thu, 23 Sep 2021 02:49:28 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B98D2610D1; Thu, 23 Sep 2021 06:47:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632379677; bh=AF60ZPwUP8z9XvN4FVZ6x/vIwqknICKlpihnYWy1TEU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Qvh3psuo++MhYg868DDM5/QIZsRvkN1DZFAmj6R7h4FhZS8cXaZN48sQjErG2rb7S boUddQRvLDXjhLRGYM11Oi0rDiEGvdN2L1a30ajG2r4+05xpJYfENvSUBJIqtpjGGz 5aYk0UDGTz3PYRcQwT84cMtPjoDUl0XoBVDx+FGo= Date: Thu, 23 Sep 2021 08:47:28 +0200 From: Greg Kroah-Hartman To: Coly Li Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-raid@vger.kernel.org, nvdimm@lists.linux.dev, antlists@youngman.org.uk, Dan Williams , Hannes Reinecke , Jens Axboe , NeilBrown , Richard Fan , Vishal L Verma , rafael@kernel.org Subject: Re: Too large badblocks sysfs file (was: [PATCH v3 0/7] badblocks improvement for multiple bad block ranges) Message-ID: References: <20210913163643.10233-1-colyli@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 23, 2021 at 02:14:12PM +0800, Coly Li wrote: > On 9/23/21 2:08 PM, Greg Kroah-Hartman wrote: > > On Thu, Sep 23, 2021 at 01:59:28PM +0800, Coly Li wrote: > > > Hi all the kernel gurus, and folks in mailing lists, > > > > > > This is a question about exporting 4KB+ text information via sysfs > > > interface. I need advice on how to handle the problem. > > Hi Greg, > > This is the code in mainline kernel for quite long time. {sigh} What tools rely on this? If none, just don't add new stuff to the file and work to create a new api instead. > > Please do not do that. Seriously, that is not what sysfs is for, and is > > an abuse of it. > > > > sysfs is for "one value per file" and should never even get close to a > > 4kb limit. If it does, you are doing something really really wrong and > > should just remove that sysfs file from the system and redesign your > > api. > > I understand this. And what I addressed is the problem I need to fix. > > The code is there for almost 10 years, I just find it during my work on bad > blocks API fixing. > > > > > Recently I work on the bad blocks API (block/badblocks.c) improvement, there > > > is a sysfs file to export the bad block ranges for me raid. E.g for a md > > > raid1 device, file > > > ??? /sys/block/md0/md/rd0/bad_blocks > > > may contain the following text content, > > > ??? 64 32 > > > ?? 128 8 > > Ick, again, that's not ok at all. sysfs files should never have to be > > parsed like this. > > I cannot agree more with you. What I am asking for was ---- how to fix it ? Best solution, come up with a new api. Worst solution, you are stuck with the existing file and I can show you the "way out" of dealing with files larger than 4kb in sysfs that a number of other apis are being forced to do as they grow over time. But ideally, just drop ths api and make a new one please. thanks, greg k-h