Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30819
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Multithreaded disk access |
| Date | 2021-10-18 16:17 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <skkva3$u6f$1@dont-email.me> (permalink) |
| References | (3 earlier) <ski6vd$hf1$1@dont-email.me> <skk2fr$ooe$1@dont-email.me> <skk753$tmp$1@dont-email.me> <skkmg9$hl3$1@dont-email.me> <skkpv8$8cc$1@dont-email.me> |
On 10/18/2021 2:46 PM, Dimiter_Popoff wrote: >> By contrast, the other disks in the machine all see a fair bit of >> turnover as things get created, revised and deleted. > > Now this is where the worst fit allocation strategy becomes the game > changer. A newly created file is almost certainly contiguously > allocated; fragmentation occurs when it is appended to (and the > space past its last block has been already allocated in the meantime). > I think I saw somewhere (never really got interested) that mainstream > operating systems of today do just first fit Dunno. There are *lots* of different "file systems". And, as most systems use the filesystem for its global namespace, the term is sadly overloaded (in ways that have nothing to do with storage media). I don't use large secondary stores in my designs. Where "big storage" is required, it is accessed remotely (network) so the problem of dealing with it is not mine. E.g., in my current project, there is no file system exposed; any persistent storage is done via "tables" that are created, as needed (by the system and its apps) in a remote database server. [This lets me delegate the issue of data retention to a specific box. And, also lets me impart structure to the data that is stored. So, for example, I can find the most recent firmware image for a particular hardware module by just issuing a query and waiting on the result instead of having to parse a bunch of names, somewhere in a filesystem/namespace, looking for the one that has the highest rev level IN its name: firmware_1.0.1, firmware_1.0.2, firmware_5.3, firmware 6.1 (typo! the '_' was omitted -- will the parse algorithm choke on that omission??)] > - which means once you > delete a file, no matter how small, its space will be allocated as > part of the next request etc., no idea why they do it (if they do so, > my memory on that is not very certain) in such a primitive manner > but here they are.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-15 07:08 -0700
Re: Multithreaded disk access Richard Damon <Richard@Damon-Family.org> - 2021-10-15 11:38 -0400
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-15 09:00 -0700
Re: Multithreaded disk access Richard Damon <Richard@Damon-Family.org> - 2021-10-15 12:48 -0400
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-15 11:40 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-15 18:46 +0300
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-15 09:19 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-15 19:28 +0300
Re: Multithreaded disk access Brett <ggtgp@yahoo.com> - 2021-10-17 20:27 +0000
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-17 14:49 -0700
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-17 15:01 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-18 01:09 +0300
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-18 08:05 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-18 19:25 +0300
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-18 13:46 -0700
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-19 00:46 +0300
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-18 16:17 -0700
Re: Multithreaded disk access antispam@math.uni.wroc.pl - 2021-10-31 19:21 +0000
Re: Multithreaded disk access Dimiter_Popoff <dp@tgi-sci.com> - 2021-10-31 21:55 +0200
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-25 04:19 -0700
Re: Multithreaded disk access Richard Damon <Richard@Damon-Family.org> - 2021-10-25 20:23 -0400
Re: Multithreaded disk access Don Y <blockedofcourse@foo.invalid> - 2021-10-25 22:29 -0700
Re: Multithreaded disk access Clifford Heath <no.spam@please.net> - 2021-10-18 11:58 +1100
csiph-web