| Zkuq said: Hmm. Aren't those initial 10 GB installations and how exactly they're spread across files likely to be more impactful for performance than whatever gets created after the game is installed? Also, aren't those initial 10 GB also likely to be split into several files by developers even on consoles? Not the whole 10 GB needs to be contiguous for efficient loading, only parts of it need to be contiguous with each other, right? For example, you can have 1 GB file for each map, containing all the assets in the map (some of it probably duplicated from other maps), and the file system is likely to find a contiguous chunk for such a smaller file even when it couldn't fit the whole 10 GB contiguosly. Sure, after enough time, the file system will look like Swiss cheese anyway, but it'll take time before that becomes too problematic. I have zero experience with developing console games, but personally I'd be really surprised if developers had zero control over how data gets stored. Files are a form of control anyway, so unless the console simply ultimately doesn't support game files, I don't see how files couldn't be used to organize data. I have no idea why the console manufacturers wouldn't allow developers to organize their data this way. Again, I'm fairly confident that each file gets stored contiguously whenever possible, and it's much easier to find contiguous spaces for relatively small files than whole files, so it's probably possible fairly often. I don't have time right now to look this up properly, but AI thinks even exFAT tries to do this, and it does seem like a fairly simple thing to do, so I don't see why it wouldn't. I'm sure there are many complications (e.g. updates, especially changes to assets), but I'm sure there are more or less effective workarounds to them as well. |
Obviously I am dumbing things down to an extreme example here... Because I haven't touched on sector sizes and how data is read/written to sectors... Or how exFAT does searches... It doesn't rely on Indexing, it relies on doing a manual search of a directory until a match is found sequentially by relying on a hash record, great for keeping CPU load down, not great for transfer rates... Which is why it's such an ideal file system for NAND.
But yes, that 10GB is going to be split into smaller files... And those files will be split up into smaller sector-sized chunks.
In short, the file system is going to write the games data to whatever free space it can, that doesn't guarentee it will be sequential.
Developers don't get to choose where data is written, because they can't. Another game may occupy that space.
With an Optical disk it's a non-issue, the developer has complete control over the optical disks contents, thus can optimize the placement of data or duplicate data to reduce seek times... It doesn't have to compete with other software.
Consequently, we just need to look at the performance deterioration of mechanical hard drives in the Xbox One and Playstation 4, they do degrade over time, not because the drives have gotten slower, but the data has become more fragmented... This has always been an issue for mechanical hard drives since they existed.
PC's tried to get around this with defrag software... But later on, File Systems tried to do it in the background when the computer wasn't being used, but exFAT doesn't have that kind of intelligence.
The Playstation 4's ext4 file system is a little more advanced than the Xbox One's exFAT and will try and optimize game installations as much as possible during install times, but that will also suffer from fragmentation and a reduction in performance over the long term just like the Xbox One... But it does happen sooner on Xbox, which sadly is because they are relying on an outdated PC file system.
www.youtube.com/@Pemalite
