7 ms·

Jurassic Cloud

100 points by dcminter 4y ago

tmikaeld 4y ago
It's interesting that XFS is the recommended filesystem for databases (event distributed ones like CochroachDB), when it does not have integrity checks that ZFS or BTRFS have. Is performance really more important than integrity for databases?
- georgia_peach 4y ago
  XFS has a long and solid track record, but without the workload-dependent regressions which can be encountered in a copy-on-write filesystem. Decent hard drives have had internal checksums for ages. If the drive is even halfway functioning, it will catch the bad blocks--making that particular ZFS feature largely redundant, and databases that matter are going to be on a RAID anyway, which has its own additional layer of parity. ZFS is fantastic for some applications, not so much for others.
  - z3t4 4y ago
    Ive had many checksum errors with ZFS, really no difference between enterprise Hdd or cheapest possible hdd (new ones). Or i just got unlucky. But some hdds are 15+ years, bad sectors but still usable.
    - georgia_peach 4y ago
      Checksum vs parity. I would wager that the drive firmware also detected the error. This is why I think ZFS checksumming is largely redundant. Parity / error correction over a zpool being another issue entirely. This is not to ding ZFS. If I were in Sun's position of having to take responsibility for 3rd-party manufactured drives, I'd have done the same thing. And circa 2006, the reliability of in-drive error detection may have been in a poorer state. Never had a corruption issue the past 10 years that wasn't preceded by months of SMART errors/warnings.
      - tmikaeld 4y ago
        It is absolutely not redundant, ZFS RAIDZ can reconstruct damaged data, thanks to the extra checksum provided by ZFS. While traditional RAID does not recover from silent data corruption because it does not know which block to reconstruct. This is exceptionally sensitive when backups are encrypted, because even a few bits off and you can't decrypt the backups. Since this happens transparently, regularly testing backups are very important in non-ZFS systems.
        georgia_peach 4y ago
        Read what I wrote more carefully. Checksumming is error detection only, while parity schemes can handle both error detection & correction. Checksumming blocks in software that are already being checksummed in hardware is redundant. Parity, on the other hand, is an essential part of any data redundancy system. For a transactional database, XFS + hardware RAID is going to be a more reliable setup than ZFS + JBOD. Database logs are similar in function to CoW, & the fancier DBs have time-machine features similar to snapshots. Having filesystem & software struggling against each other to solve the same problem, but with different solutions, is a situation that invites so many Heisenbugs. That, and a good RAID controller is going to handle drive-reported errors sooner and more gracefully than a ZFS scrub.
- mrweasel 4y ago
  I don't have the answer, but it's an interesting question. Given that XFS doesn't do replication, like ZFS or BTRFS does, having integrity checks is a bit weird. If a check fails, what is XFS suppose to do about it? If the filesystem can "recover" or deal with failed integrity checks, it makes sense to have them at that layer. If it can't, I'd say that the application, in this case a database, should do it's own integrity checks. If it's just a few rows or tables, the operator can easily recover those from a backup. Having the filesystem, which knows nothing about the data, report the failure will mean having to do a full restore from backups.
  - tmikaeld 4y ago
    ZFS RAIDZ can reconstruct damaged data, thanks to the extra checksum provided by ZFS. While traditional RAID does not recover from silent data corruption because it does not know which block to reconstruct. This is exceptionally sensitive when backups are encrypted, because even a few bits off and you can't decrypt the backups. Since this happens transparently, regularly testing backups are very important in non-ZFS systems.
    - dijit 4y ago
      ZFS is more akin to a logical volume manager (inc. software raid) and a filesystem though. XFS is just a filesystem, it's not trying to solve the same issues. Higher end RAID cards also do block level validations in the background. It isn't filesystem aware but it is sufficient to suss out bad clusters and relocate data proactively. The point of ZFS systems is to avoid such hardware based checksumming systems, but RAID cards have been doing this validation for many years now. The hardware solutions we have now provide silent corruption protection from the storage controller down to the actual media. ZFS extends that protection to the filesystem layer in the kernel and when used in isolation of modern hardware solutions can protect the whole stack.
throwaway787544 4y ago
Filesystems are close to being obsolete in the cloud. We still need them to get applications "started", but after that, applications shouldn't really be using a filesystem. I/O should take place with a remote (or local) service that deals with the many moving parts behind the thing the application really wants (look up some data, read some data, write some data, delete some data) in a large distributed system (logging, tracing, authn+z, storing/retrieving, sharing, archiving, etc). How it gets stored and on what media is pretty inconsequential to the app, and in many cases things are just more difficult because of the inherent limitations of storing data in files in filesystems on disks. The other thing is, once disks are as fast as RAM, there's really no point in having RAM. It only exists because running programs would have been really slow if we had to wait for the disk to seek 100 times to print "Hello World". Combine these two scenarios and you land smack into one new reality: all applications should be doing I/O in a giant pool of state that is both data storage and computational memory, as a global, distributed, virtual storage memory manager. In effect, clusters of computers should be sharing CPU and storage, and applications should run across all of those resources, like one big computer cut into 100 pieces. The idea of this was called SSI before, but it can actually become reality a lot easier if we can make the abstractions so simple that we don't have to code around ugly problems like threaded-shared-memory apps. Basically we need to make a new "layer" that will allow us to delete a couple of old ones, and that simplicity will enable whole new designs and make currently-hard problems easy.
- slindz 4y ago
  Sounds a lot like erlang. Elixir has been my daily driver since 2016; still loving it.
- tmikaeld 4y ago
  Combining NVM and RAM has been in progress for a long time: https://en.wikipedia.org/wiki/Resistive_random-access_memory https://en.wikipedia.org/wiki/Resistive_random-access_memory But there seems to be a lot of more research needed before the gap is even close to being closed.
- londons_explore 4y ago
  There is sadly still a huge performance gap between most filesystems and other storage API's. If you tried to boot windows with all system files stored on S3, it would take forever. It turns out the overhead of HTTP, encoding, many memory copies, splitting into TCP/UDP packets, etc. Is huge compared to a DMA transfer straight from an SSD into an applications memory space.
pjmlp 4y ago
> Linux is almost 30 years old, Postgres and MySQL are over 25. The core of “modern” clouds such as AWS, GCP and Azure is 15 years old if not older. It is even more Jurassic than this, if we take into account the first commercial uses of UNIX, SQL/DS, and System/370.
z3t4 4y ago
When we are talking nanoseconds or low microseconds the distance is still important - networking has become a lot faster, but we are still talking milliseconds when doing stuff in the "cloud", if not seconds if we are talking enterprise/business software in the cloud. Distributed systems have few advantages and many disadvantages. For speed/performance keep the data as local as possible.
- Cthulhu_ 4y ago
  > For speed/performance keep the data as local as possible. Yeah, I agree. For scalability and resilience though, the cloud based design patterns - async queues and workers, eventual consistency, etc - is probably better. I've yet to really have a need for something like that though.
georgia_peach 4y ago
I would prefer a computer that was slower, but worked the way it was supposed to (i.e. without rowhammer & spec-ex bugs, AMT/secret minix kernel, encrypted microcode mystery-meat, etc). The typical user doesn't need to bean-count every microsecond. He desperately needs a computer that is his own tool rather than an infosec quagmire & the business-end of tech sector money-proboscis. It is, sadly, the path of least resistance. "Big number good" is much easier for a consumer to grasp than the (qualitative) corners that were cut to achieve those big numbers. Lies, damn lies, & benchmarks! The combinatorics of making distributed the new default are astronomical. That he dashes this all off so lightly, and in so little detail, makes me wonder if he's ever really done the work. Whether he has, or he hasn't, this is still 100% the wrong direction for anyone outside of a data center.
- pas 4y ago
  > The typical user [...] He desperately needs a [...] citation needed. typical users want communication, entertainment, in general they want to achieve ends, and for them the important thing about the means is that it should look good/cool. hence Apple things.
  - georgia_peach 4y ago
    My computers from 15 years ago, PC or Mac, did all of these things--even high-res FPS games--beautifully. If all you do is surf/email/music/video/games--and I don't think it requires a citation to believe that this is the lion's share of users--current speeds are beyond sufficient. The quality issues in modern machines are the byproduct of a quantity-cult pissing contest rather than necessity. If anything, the excesses are only wasted by sloppier software (which was enabled by the excess to begin with), piggier websites, covert crypto miners, etc. Wirth's law is a vicious cycle. And it's a false economy: cut corners on the clean-up of discarded speculative branches, get some great numbers on the latest benchmark; the chipmakers who stoop to this get an edge in the market, but by the time it hits the consumer (who has no understanding of such things), the mitigation costs exceed the original "improvement". Because it is such a multi-variate & workload-dependent situation, it may not be cut-and-dry fraud, even though it smells a lot like it.
kgeist 4y ago
>How many would notice, if we hijacked runtime calls and wrote to a remote blob storage instead of disks We replaced all file access with calls to S3 storage a few months ago (the goal was to make the service completely stateless, for other technical reasons) and just yesterday we had yet another connectivity problem to S3 storage. Disks break too but it feels like connectivity issuses are much more frequent, at least in our country
- zasdffaa 4y ago
  Which is innately more fragile, a communication system you rely on for data that runs dozens to hundreds of miles through some communication medium that you don't control, to disks. Or a disk (or five) in your own chassis. It's not quite that simple, but still...
  - jl6 4y ago
    An alternative perspective - which is innately more fragile: a communication system with support and incident management by professionals whose sole job it is to keep the system running 24x7 and bring it back online in the rare event it fails; or, you, whose main job is something else entirely, and you would rather not have to think about disks at all.
    - zasdffaa 4y ago
      That's a very good point. For: I've seen a company very nearly destroyed by not having the skills to deal with a single disk failure in raid. Against: A Large Hosting Company we used couldn't read my simple instructions and lost a backup. BTW read the SLAs of your provider and my guess is you'll agree with what a lawyer who worked for us said - shite. Basically, while it was down our provider wouldn't charge us for it. The end. What does yours do? If similar, what motivation have they to fix breaks? And is the provider responsible for loss of connectivity between them and you? Put another way, who gets hurt more in downtime, the provider or you? Some reading for me <https://journal.uptimeinstitute.com/cloud-slas-punish-not-compensate/ https://journal.uptimeinstitute.com/cloud-slas-punish-not-co...> Quick extract: "SLA compensation doesn’t even scratch the surface of these losses. If a single virtual machine goes down for less than 7 hours, 18 minutes (99% monthly availability), AWS will pay 10% of the monthly cost of that virtual machine. Considering the price of a small instance (a ‘t4g.nano’) in the large US-East-1 region (in Northern Virginia, US) is around $3 per month, total compensation for this outage would be 30 cents. If a virtual machine goes down for less than 36 hours (95% availability in a month), the compensation is just 30% — just under a dollar. The user only receives a full refund for the month if the resource is down for more than one day, 12 hours and 31 minutes in total." yep, that sounds about right. Edit for context: "In the 2021 Uptime Institute data center survey, the average cost of respondents’ most significant recent downtime incident was $973,000. This average does not include the 2% of respondents who estimate they lost more than $40M for their most recent worst downtime incident."
sandworm101 4y ago
Should mention Kerbal Space Program in this context. Rather than deal with complicated IO, moving data between disks and ram, the devs just loaded absolutely everything into memory at program start. This had all sorts of trickle-down benefits. In my experience, many Linux versions of that huge game were more stable than basic office software.
- badpun 4y ago
  That's pretty standard approach in games. This negates problems with loads during gameplay potentially making game choppy, and also makes you aware of your total maximum memory budget (important esp. for consoles) - whereas, with dynamic loads and mallocs, you'll only find that out via extensive testing.
  - sandworm101 4y ago
    Not unless your game is less than a few gigs in total size. The average size of a 3d simulation game is much larger than the 8/16gb of memory on typical gaming rigs. KSP loaded literally everything, every texture, at startup. The only time the drive was touched after that was for saves.
- z3t4 4y ago
  KSP (the original) use the Unity engine. When the original devs quit, the game got more and more buggy, to the point it was unplayable, kept crashing every other hour or so... I played without quicksaving for a more tense experience - and the crashes ruined that.
  - LtdJorge 4y ago
    AFAIK it still uses Unity
    - ceejayoz 4y ago
      It's pretty rock-solid on my M1 Macbook these days, too.
smelbe 4y ago
It's intriguing that XFS, which lacks the integrity checks that ZFS or BTRFS offer, is the recommended filesystem for databases, even distributed ones like CochroachDB.
- georgia_peach 4y ago
  The main log provides CoW-like functionality, & archive logs provide snapshot-like functionality. Having the DB & the file system duel over these responsibilities is trouble waiting to happen.
- sterwill 4y ago
  I don't have any experience with ZFS, and very little with BTRFS, but the reason I pick XFS is that has "just worked", out of the box, on every Linux distribution I've managed for about 20 years. Back then, it was one of the few choices that didn't have a static inode limit, and it could be grown while mounted. That was a big convenience on file servers when combined with LVM and/or hardware RAID. ZFS sounds hard to manage, I thought BTRFS was still eating peoples' data for a while, and XFS just keeps working fine.
  - deleted 4y ago
    [deleted]
  - onphonenow 4y ago
    Same - aws I think uses by default for the same reason
christophilus 4y ago
Oh, man. My first thought was, “Don’t let Jonathan Blow see this.” Second thought was, “This is kinda the Eelctron mentality, only applied to disks.” Then my mind went blank because I haven’t had enough caffeine yet. Two thoughts is all I have.
deleted 4y ago
[deleted]

100 points by dcminter 4y ago

It's interesting that XFS is the recommended filesystem for databases (event distributed ones like CochroachDB), when it does not have integrity checks that ZFS or BTRFS have. Is performance really more important than integrity for databases?

georgia_peach 4y ago
XFS has a long and solid track record, but without the workload-dependent regressions which can be encountered in a copy-on-write filesystem. Decent hard drives have had internal checksums for ages. If the drive is even halfway functioning, it will catch the bad blocks--making that particular ZFS feature largely redundant, and databases that matter are going to be on a RAID anyway, which has its own additional layer of parity. ZFS is fantastic for some applications, not so much for others.
- z3t4 4y ago
  Ive had many checksum errors with ZFS, really no difference between enterprise Hdd or cheapest possible hdd (new ones). Or i just got unlucky. But some hdds are 15+ years, bad sectors but still usable.
  - georgia_peach 4y ago
    Checksum vs parity. I would wager that the drive firmware also detected the error. This is why I think ZFS checksumming is largely redundant. Parity / error correction over a zpool being another issue entirely. This is not to ding ZFS. If I were in Sun's position of having to take responsibility for 3rd-party manufactured drives, I'd have done the same thing. And circa 2006, the reliability of in-drive error detection may have been in a poorer state. Never had a corruption issue the past 10 years that wasn't preceded by months of SMART errors/warnings.
    - tmikaeld 4y ago
      It is absolutely not redundant, ZFS RAIDZ can reconstruct damaged data, thanks to the extra checksum provided by ZFS. While traditional RAID does not recover from silent data corruption because it does not know which block to reconstruct. This is exceptionally sensitive when backups are encrypted, because even a few bits off and you can't decrypt the backups. Since this happens transparently, regularly testing backups are very important in non-ZFS systems.
      - georgia_peach 4y ago
        Read what I wrote more carefully. Checksumming is error detection only, while parity schemes can handle both error detection & correction. Checksumming blocks in software that are already being checksummed in hardware is redundant. Parity, on the other hand, is an essential part of any data redundancy system. For a transactional database, XFS + hardware RAID is going to be a more reliable setup than ZFS + JBOD. Database logs are similar in function to CoW, & the fancier DBs have time-machine features similar to snapshots. Having filesystem & software struggling against each other to solve the same problem, but with different solutions, is a situation that invites so many Heisenbugs. That, and a good RAID controller is going to handle drive-reported errors sooner and more gracefully than a ZFS scrub.
mrweasel 4y ago
I don't have the answer, but it's an interesting question. Given that XFS doesn't do replication, like ZFS or BTRFS does, having integrity checks is a bit weird. If a check fails, what is XFS suppose to do about it? If the filesystem can "recover" or deal with failed integrity checks, it makes sense to have them at that layer. If it can't, I'd say that the application, in this case a database, should do it's own integrity checks. If it's just a few rows or tables, the operator can easily recover those from a backup. Having the filesystem, which knows nothing about the data, report the failure will mean having to do a full restore from backups.
- tmikaeld 4y ago
  ZFS RAIDZ can reconstruct damaged data, thanks to the extra checksum provided by ZFS. While traditional RAID does not recover from silent data corruption because it does not know which block to reconstruct. This is exceptionally sensitive when backups are encrypted, because even a few bits off and you can't decrypt the backups. Since this happens transparently, regularly testing backups are very important in non-ZFS systems.
  - dijit 4y ago
    ZFS is more akin to a logical volume manager (inc. software raid) and a filesystem though. XFS is just a filesystem, it's not trying to solve the same issues. Higher end RAID cards also do block level validations in the background. It isn't filesystem aware but it is sufficient to suss out bad clusters and relocate data proactively. The point of ZFS systems is to avoid such hardware based checksumming systems, but RAID cards have been doing this validation for many years now. The hardware solutions we have now provide silent corruption protection from the storage controller down to the actual media. ZFS extends that protection to the filesystem layer in the kernel and when used in isolation of modern hardware solutions can protect the whole stack.

throwaway787544 4y ago

Filesystems are close to being obsolete in the cloud. We still need them to get applications "started", but after that, applications shouldn't really be using a filesystem. I/O should take place with a remote (or local) service that deals with the many moving parts behind the thing the application really wants (look up some data, read some data, write some data, delete some data) in a large distributed system (logging, tracing, authn+z, storing/retrieving, sharing, archiving, etc). How it gets stored and on what media is pretty inconsequential to the app, and in many cases things are just more difficult because of the inherent limitations of storing data in files in filesystems on disks. The other thing is, once disks are as fast as RAM, there's really no point in having RAM. It only exists because running programs would have been really slow if we had to wait for the disk to seek 100 times to print "Hello World". Combine these two scenarios and you land smack into one new reality: all applications should be doing I/O in a giant pool of state that is both data storage and computational memory, as a global, distributed, virtual storage memory manager. In effect, clusters of computers should be sharing CPU and storage, and applications should run across all of those resources, like one big computer cut into 100 pieces. The idea of this was called SSI before, but it can actually become reality a lot easier if we can make the abstractions so simple that we don't have to code around ugly problems like threaded-shared-memory apps. Basically we need to make a new "layer" that will allow us to delete a couple of old ones, and that simplicity will enable whole new designs and make currently-hard problems easy.

slindz 4y ago
Sounds a lot like erlang. Elixir has been my daily driver since 2016; still loving it.
tmikaeld 4y ago
Combining NVM and RAM has been in progress for a long time: https://en.wikipedia.org/wiki/Resistive_random-access_memory https://en.wikipedia.org/wiki/Resistive_random-access_memory But there seems to be a lot of more research needed before the gap is even close to being closed.
londons_explore 4y ago
There is sadly still a huge performance gap between most filesystems and other storage API's. If you tried to boot windows with all system files stored on S3, it would take forever. It turns out the overhead of HTTP, encoding, many memory copies, splitting into TCP/UDP packets, etc. Is huge compared to a DMA transfer straight from an SSD into an applications memory space.

pjmlp 4y ago

> Linux is almost 30 years old, Postgres and MySQL are over 25. The core of “modern” clouds such as AWS, GCP and Azure is 15 years old if not older. It is even more Jurassic than this, if we take into account the first commercial uses of UNIX, SQL/DS, and System/370.

z3t4 4y ago

When we are talking nanoseconds or low microseconds the distance is still important - networking has become a lot faster, but we are still talking milliseconds when doing stuff in the "cloud", if not seconds if we are talking enterprise/business software in the cloud. Distributed systems have few advantages and many disadvantages. For speed/performance keep the data as local as possible.

Cthulhu_ 4y ago
> For speed/performance keep the data as local as possible. Yeah, I agree. For scalability and resilience though, the cloud based design patterns - async queues and workers, eventual consistency, etc - is probably better. I've yet to really have a need for something like that though.

georgia_peach 4y ago

I would prefer a computer that was slower, but worked the way it was supposed to (i.e. without rowhammer & spec-ex bugs, AMT/secret minix kernel, encrypted microcode mystery-meat, etc). The typical user doesn't need to bean-count every microsecond. He desperately needs a computer that is his own tool rather than an infosec quagmire & the business-end of tech sector money-proboscis. It is, sadly, the path of least resistance. "Big number good" is much easier for a consumer to grasp than the (qualitative) corners that were cut to achieve those big numbers. Lies, damn lies, & benchmarks! The combinatorics of making distributed the new default are astronomical. That he dashes this all off so lightly, and in so little detail, makes me wonder if he's ever really done the work. Whether he has, or he hasn't, this is still 100% the wrong direction for anyone outside of a data center.

pas 4y ago
> The typical user [...] He desperately needs a [...] citation needed. typical users want communication, entertainment, in general they want to achieve ends, and for them the important thing about the means is that it should look good/cool. hence Apple things.
- georgia_peach 4y ago
  My computers from 15 years ago, PC or Mac, did all of these things--even high-res FPS games--beautifully. If all you do is surf/email/music/video/games--and I don't think it requires a citation to believe that this is the lion's share of users--current speeds are beyond sufficient. The quality issues in modern machines are the byproduct of a quantity-cult pissing contest rather than necessity. If anything, the excesses are only wasted by sloppier software (which was enabled by the excess to begin with), piggier websites, covert crypto miners, etc. Wirth's law is a vicious cycle. And it's a false economy: cut corners on the clean-up of discarded speculative branches, get some great numbers on the latest benchmark; the chipmakers who stoop to this get an edge in the market, but by the time it hits the consumer (who has no understanding of such things), the mitigation costs exceed the original "improvement". Because it is such a multi-variate & workload-dependent situation, it may not be cut-and-dry fraud, even though it smells a lot like it.

kgeist 4y ago

>How many would notice, if we hijacked runtime calls and wrote to a remote blob storage instead of disks We replaced all file access with calls to S3 storage a few months ago (the goal was to make the service completely stateless, for other technical reasons) and just yesterday we had yet another connectivity problem to S3 storage. Disks break too but it feels like connectivity issuses are much more frequent, at least in our country

zasdffaa 4y ago
Which is innately more fragile, a communication system you rely on for data that runs dozens to hundreds of miles through some communication medium that you don't control, to disks. Or a disk (or five) in your own chassis. It's not quite that simple, but still...
- jl6 4y ago
  An alternative perspective - which is innately more fragile: a communication system with support and incident management by professionals whose sole job it is to keep the system running 24x7 and bring it back online in the rare event it fails; or, you, whose main job is something else entirely, and you would rather not have to think about disks at all.
  - zasdffaa 4y ago
    That's a very good point. For: I've seen a company very nearly destroyed by not having the skills to deal with a single disk failure in raid. Against: A Large Hosting Company we used couldn't read my simple instructions and lost a backup. BTW read the SLAs of your provider and my guess is you'll agree with what a lawyer who worked for us said - shite. Basically, while it was down our provider wouldn't charge us for it. The end. What does yours do? If similar, what motivation have they to fix breaks? And is the provider responsible for loss of connectivity between them and you? Put another way, who gets hurt more in downtime, the provider or you? Some reading for me <https://journal.uptimeinstitute.com/cloud-slas-punish-not-compensate/ https://journal.uptimeinstitute.com/cloud-slas-punish-not-co...> Quick extract: "SLA compensation doesn’t even scratch the surface of these losses. If a single virtual machine goes down for less than 7 hours, 18 minutes (99% monthly availability), AWS will pay 10% of the monthly cost of that virtual machine. Considering the price of a small instance (a ‘t4g.nano’) in the large US-East-1 region (in Northern Virginia, US) is around $3 per month, total compensation for this outage would be 30 cents. If a virtual machine goes down for less than 36 hours (95% availability in a month), the compensation is just 30% — just under a dollar. The user only receives a full refund for the month if the resource is down for more than one day, 12 hours and 31 minutes in total." yep, that sounds about right. Edit for context: "In the 2021 Uptime Institute data center survey, the average cost of respondents’ most significant recent downtime incident was $973,000. This average does not include the 2% of respondents who estimate they lost more than $40M for their most recent worst downtime incident."

sandworm101 4y ago

Should mention Kerbal Space Program in this context. Rather than deal with complicated IO, moving data between disks and ram, the devs just loaded absolutely everything into memory at program start. This had all sorts of trickle-down benefits. In my experience, many Linux versions of that huge game were more stable than basic office software.

badpun 4y ago
That's pretty standard approach in games. This negates problems with loads during gameplay potentially making game choppy, and also makes you aware of your total maximum memory budget (important esp. for consoles) - whereas, with dynamic loads and mallocs, you'll only find that out via extensive testing.
- sandworm101 4y ago
  Not unless your game is less than a few gigs in total size. The average size of a 3d simulation game is much larger than the 8/16gb of memory on typical gaming rigs. KSP loaded literally everything, every texture, at startup. The only time the drive was touched after that was for saves.
z3t4 4y ago
KSP (the original) use the Unity engine. When the original devs quit, the game got more and more buggy, to the point it was unplayable, kept crashing every other hour or so... I played without quicksaving for a more tense experience - and the crashes ruined that.
- LtdJorge 4y ago
  AFAIK it still uses Unity
  - ceejayoz 4y ago
    It's pretty rock-solid on my M1 Macbook these days, too.

smelbe 4y ago

It's intriguing that XFS, which lacks the integrity checks that ZFS or BTRFS offer, is the recommended filesystem for databases, even distributed ones like CochroachDB.

georgia_peach 4y ago
The main log provides CoW-like functionality, & archive logs provide snapshot-like functionality. Having the DB & the file system duel over these responsibilities is trouble waiting to happen.
sterwill 4y ago
I don't have any experience with ZFS, and very little with BTRFS, but the reason I pick XFS is that has "just worked", out of the box, on every Linux distribution I've managed for about 20 years. Back then, it was one of the few choices that didn't have a static inode limit, and it could be grown while mounted. That was a big convenience on file servers when combined with LVM and/or hardware RAID. ZFS sounds hard to manage, I thought BTRFS was still eating peoples' data for a while, and XFS just keeps working fine.
- deleted 4y ago
  [deleted]
- onphonenow 4y ago
  Same - aws I think uses by default for the same reason

christophilus 4y ago

Oh, man. My first thought was, “Don’t let Jonathan Blow see this.” Second thought was, “This is kinda the Eelctron mentality, only applied to disks.” Then my mind went blank because I haven’t had enough caffeine yet. Two thoughts is all I have.

deleted 4y ago

[deleted]