-
-
Notifications
You must be signed in to change notification settings - Fork 84
Use separate mounted disk for persistence #152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Fidelity
Emulation fidelity (vs native builds and/or real hardware)
Comments
mihaip
added a commit
that referenced
this issue
Apr 15, 2023
Instead generating fiels into the virtual Emscripten file system (that the emulators then read using POSIX APIs), expose a workerApi.disks.* API that the emulators can use (implemented in mihaip/minivmac@e351655 and mihaip/macemu@4824c50). This allows lazy loading to be handled more directly, without a pre-allocated array of the size of the disk image. There is now a EmulatorWorkerDisk interface with two separate implementations (EmulatorWorkerChunkedDisk, EmulatorWorkerUploadDisk), and more can be plugged in (e.g. for #152). Fixes #56
mihaip
added a commit
that referenced
this issue
Aug 18, 2023
Add a mode where we persist the changes made to a chunked disk image in the origin private file system feature that is supported by modern browsers. They also support being able to get a synchronous file handle, which allows us to directly intercept read/write calls from the emulator with no complications. The persistence is handled as an overlay on top of the chunked data, we have a separate dirty chunks bitmask that stores which chunks have been modified. When we're about to read from a chunk, we first load it from the persisted disk. Similarly, when a change to a chunk is made, we mark it as dirty and write it to the persisted disk. This does mean that there is some write amplification (any change writes a whole 256K chunk), but in practice performance appears to be OK (the native file system cache kicks in presumably). Since the disk image is mostly empty, we stored it compressed in Git (to avoid having a large file). We also optimize empty chunks, so that we don't need to store a signature for them, or load them over the network. To feature detect if the browser supports the origin private file system and synchronous file handles, we need to create a temporary worker (FileSystemSyncAccessHandle is only ever defined in workers). We cache the result of this check in localStorage so that we don't need to do it too often. Currently disabled by default, but accessible via the custom instance dialog or the ?saved_hd=true query parameter Updates #152
mihaip
added a commit
that referenced
this issue
Aug 20, 2023
It'll be getting more complex if we're adding settings related to persistence. Updates #152
mihaip
added a commit
that referenced
this issue
Aug 20, 2023
I looked into doing this automatically (e.g. when there's a click in the emulator), but persistence does not seem to be granted easily in Chrome, so I'm letting it be explicit for now. Updates #152
mihaip
added a commit
that referenced
this issue
Aug 20, 2023
The old version of the lifesaver icon was edge-to-edge, but that ends up touching the name/label in the Finder, which does not look good. Updates #152
mihaip
added a commit
that referenced
this issue
Aug 20, 2023
To simplify the implementation this is done in the the UI process. We need to stop the emulator (so that it doesn't try to write to the disk and picks up changes), and if we need to stop it, we might as well do the reset in the UI process (where we can more easily use async/await) Updates #152
mihaip
added a commit
that referenced
this issue
Aug 20, 2023
Done via a .zip that contains the dirty chunks and data file. Updates #152
mihaip
added a commit
that referenced
this issue
Aug 21, 2023
The base image and dirty chunks are merged into a .dsk image that can be loaded into other (native) emulators. Updates #152
mihaip
added a commit
that referenced
this issue
Aug 24, 2023
It's possible that it has a a system folder on it, and thus all that's needed. Updates #152
mihaip
added a commit
that referenced
this issue
Aug 24, 2023
mihaip
added a commit
that referenced
this issue
Aug 26, 2023
Also moves such intro texts out of import-disks.py and into a "strings" subdirectory so that they're easier to edit. Updates #152
mihaip
added a commit
that referenced
this issue
Aug 26, 2023
Mostly out of hygiene, but also picks up TypeScript type definitionss for createWritable on FileSystemFileHandle. Updates #152
mihaip
added a commit
that referenced
this issue
Aug 26, 2023
mihaip
added a commit
that referenced
this issue
Aug 26, 2023
mihaip
added a commit
that referenced
this issue
Aug 26, 2023
mihaip
added a commit
that referenced
this issue
Sep 10, 2023
Also reference it in the in-app documentation. Updates #152
mihaip
added a commit
that referenced
this issue
Sep 10, 2023
Only shown if we restore any files to it. Also fixes usePersistentState to actually persist changes -- it read from localStorage but wrote to sessionStorage, so it never actually persisted anything. Updates #152
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Instead of relying on ExtFS (which is not available on Mini vMac/System 6 and older), there could be a separate disk that gets mounted that has its contents persisted. Would rely on the changes made for #56 to have more direct hooks when reads/write happen.
createSyncAccessHandle
and other APIs)run-def.ts
andCustom.tsx
)Batch chunk writes (viaperiodicTasks
?) and also callflush()
at that time -> not worth it, risk of data lossThe text was updated successfully, but these errors were encountered: