Re: Too large badblocks sysfs file (was: [PATCH v3 0/7] badblocks improvement for multiple bad block ranges)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/23/21 2:47 PM, Greg Kroah-Hartman wrote:
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.

At least I know mdadm uses this sysfs interface for md raid component disks monitoring. It has been in mdadm for around 5 years.

Yes you are right, let it be for existing sysfs interface to avoid breaking things.

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.

Now I am sure you are very probably not willing to accept the patches, even I know how to do that :-)


But ideally, just drop ths api and make a new one please.

OK, then I leave the existing things as what they are, avoid to make them worse.

Thanks for your response.

Coly Li




[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux