linux-kernel - Re: vfat file system extreme fragmentation on multiprocessor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <0ML25U-1KdwSf0P4s-0006TS@mrelayeu.kundenserver.de>
Date:	Fri, 12 Sep 2008 01:03:03 +0200
From:	Harun Scheutzow <harun04@...eutzow.de>
To:	linux-kernel@...r.kernel.org
Cc:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
Subject: Re: vfat file system extreme fragmentation on multiprocessor

Why should C library fwrite() split anything? There is no good reason (unless in x86 64 KByte segmented model trying to emulate a flat model - old DOS). The 50 MByte go to write() in a single piece here.

There are only very little "single operation"s in kernel nowadays. In most cases this is a good thing.

Looks like fat/fatent.c fat_alloc_clusters() is limited to allocate only 4 clusters under a single lock.

Found another assumption I do not like: cluster size >= 512. There are old FAT systems on SRAM cards having 128 byte/sector and cluster. But I don't want to have long filenames on them. Hope the 512 does not sit elsewhere, too.

fat/inode.c __fat_get_block() /* TODO: multiple cluster allocation would be desirable */
YES, OF COURSE. Only a single cluster is allocated at a time, no lock here, I can be happy I got still 8 clusters per fragment, might have been only 1.

Harun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/