[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YUwZ95Z+L5M3aZ9V@kroah.com>
Date: Thu, 23 Sep 2021 08:08:55 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Coly Li <colyli@...e.de>
Cc: linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
linux-raid@...r.kernel.org, nvdimm@...ts.linux.dev,
antlists@...ngman.org.uk, Dan Williams <dan.j.williams@...el.com>,
Hannes Reinecke <hare@...e.de>, Jens Axboe <axboe@...nel.dk>,
NeilBrown <neilb@...e.de>, Richard Fan <richard.fan@...e.com>,
Vishal L Verma <vishal.l.verma@...el.com>, rafael@...nel.org
Subject: Re: Too large badblocks sysfs file (was: [PATCH v3 0/7] badblocks
improvement for multiple bad block ranges)
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.
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.
> 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.
thanks,
greg k-h
Powered by blists - more mailing lists