1.1--- a/.hgsubstate Mon Nov 20 21:13:44 2023 -0500
1.2+++ b/.hgsubstate Fri Nov 24 22:39:07 2023 -0500
1.3@@ -1,2 +1,2 @@
1.4-ae3d87d236cfb817b50cc8e41614df11a872c1d2 blog
1.5-1c57e053f043e7f164e18edda6edfc235662cadb docs
1.6+5747098f52b4e128741024c159ea5af83ef85485 blog
1.7+bb51c61e4d4b800f08abf14a791d8ecb7fdab353 docs
2.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
2.2+++ b/notes/20230730.org Fri Nov 24 22:39:07 2023 -0500
2.3@@ -0,0 +1,36 @@
2.4+* VC infrastructure
2.5+In heptapod we have a root group named =comp=, containg a variety of
2.6+subgroups. Some of these groups should be public, while others are
2.7+internal to comp members exclusively. Within each subgroup, we should
2.8+have the root group members automatically granted privileged access to
2.9+projects. This is relevant for the =startup= subgroup in particular,
2.10+where each project is potentially maintained by multiple non-root
2.11+contributors.
2.12+
2.13+We also need to consider how we will manage subrepos across the
2.14+organization. It is about time we start integrating HG bundles and
2.15+potentially mirrors. For our core VC pipeline we should have no
2.16+reliance on Git, but this may be difficult. It depends on the behavior
2.17+of HG bundles.
2.18+
2.19+Bookmarks/tags should be used for milestones in the root group and are
2.20+infrequent. They are more frequent in projects with a regular release
2.21+life-cycle.
2.22+* Approaching Webapps
2.23+I started poking around in the webapp space again so that I can launch
2.24+a landing page for NAS-T quickly. The Rust situation has improved
2.25+somewhat on the frontend side, and the axum backend stack is nice.
2.26+
2.27+This might seem like a lot of Rust and not a lot of Lisp, which it is,
2.28+but there's still room for Lisp wherever we need it. It mostly plays a
2.29+role in the backend, servicing the database and responding to requests
2.30+from the Rust edges. All of the important tests for the web APIs are
2.31+also written in Lisp. We will almost certainly use Lisp for all static
2.32+processing and HTML generation at compile-time.
2.33+
2.34+This I believe, is the appropriate way to integrate Lisp into a
2.35+cutting-edge web-app. You get the good parts of Lisp where you need
2.36+them (interactive debugging, dynamic language, REPL) and avoid the bad
2.37+parts (OOB optimization, RPS performance) in areas where the customer
2.38+would be impacted. In this domain, Lisp takes the form of a glue
2.39+rather than the bricks and mortar it sometimes appears to us as.
3.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
3.2+++ b/notes/20231024.org Fri Nov 24 22:39:07 2023 -0500
3.3@@ -0,0 +1,59 @@
3.4+* virt
3.5+** QEMU
3.6+** KVM
3.7+** Hyper-V
3.8+** Firecracker
3.9+** Docker
3.10+** Vagrant
3.11+** LXC
3.12+** LXD
3.13+** containerd
3.14+** systemd-nspawn
3.15+** VirtualBox
3.16+
3.17+* Concatenative
3.18+** Factor :factor:
3.19+- [2023-07-04 Tue]
3.20+ Factor is a cool concatenative lang but unfortunately the C interface
3.21+ (vm/master.h) no longer exists on the master branch.
3.22+** Joy :joy:
3.23+
3.24+*** https://hypercubed.github.io/joy/html/j02maf.html
3.25+
3.26+*** [[https://builds.openlogicproject.org/content/incompleteness/arithmetization-syntax/arithmetization-syntax.pdf][arithmetization of syntax]]
3.27+* Lisp :lisp:
3.28+These notes pertain to Lisp. More specifically, ANSI Common Lisp in
3.29+most places.
3.30+
3.31+- https://github.com/lispnik/iup/ - doesn't support MacOS yet, looks
3.32+ cool though
3.33+ - what we really need is wasm compiler.. TBD
3.34+* Rust
3.35+** Serde
3.36+- [2023-07-05 Wed] \\
3.37+ important part of the Rust ecosystem, another dtolnay
3.38+ contribution. If you want to program a /data/ format in the Rust
3.39+ ecosystem, this is how you do it.
3.40+
3.41+ The way it works is that you define some special structs, a
3.42+ Serializer and a Deserializer which implement the Serialize and
3.43+ Deserialize traits provided by serde, respectively.
3.44+
3.45+ You can use these structs to provide your public API. The
3.46+ conventional choice is public top-level functions like from-str
3.47+ and to-string. That's it, your serialization library can now read and
3.48+ write your data format as Rust data types.
3.49+
3.50+ [[https://serde.rs/enum-representations.html][enum-representations]]
3.51+ - the default behavior is an externally tagged representation (verbose)
3.52+
3.53+ The docs use strings as core IO when implementing a custom format,
3.54+ but the convention is to implement for T where T is bound by std::io
3.55+ Read or Write trait. Then you can provide a more robust public API
3.56+ (from_bytes, from_writer, etc).
3.57+* C
3.58+* CPP
3.59+* Nu
3.60+[[https://www.nushell.sh/][~]]
3.61+[[https://www.nushell.sh/cookbook/][cookbook]]
3.62+[[https://github.com/nushell/nu_scripts][nu_scripts]]
4.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
4.2+++ b/notes/20231101.org Fri Nov 24 22:39:07 2023 -0500
4.3@@ -0,0 +1,18 @@
4.4+* AWS usage
4.5+We're leveraging AWS for some of our public web servers for now. It's
4.6+really not realistic to expect that my home desktop and spotty Comcast
4.7+internet can serve any production workflow. What it /is/ capable of is
4.8+a private VPN, which can communicate with AWS and other cloud VPN
4.9+depots via WireGuard ([[https://dev.to/gabrieltetzner/setting-up-a-vpn-with-wireguard-server-on-aws-ec2-4a49][article]]).
4.10+
4.11+I currently use Google Domains for nas-t.net, otom8.dev, and
4.12+rwest.io - but that business is now owned by squarespace, so I would
4.13+rather move it to Route53.
4.14+
4.15+We have archlinux ec2 image builds [[https://wiki.archlinux.org/title/Arch_Linux_AMIs_for_Amazon_Web_Services][here]] and [[https://gitlab.com/anemos-io/archlinux-ec2][here]] - only half work and not
4.16+maintained, but it's a start. I'm not even sure if I should stick with
4.17+arch or cave and use Ubuntu or AWS Linux. We can serve the static
4.18+services with little cost, the only big spender will be the heptapod
4.19+instance which requires a larger instance and some workers.
4.20+
4.21+We'll try to keep the cost at or around $30/month.
5.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
5.2+++ b/notes/20231102.org Fri Nov 24 22:39:07 2023 -0500
5.3@@ -0,0 +1,82 @@
5.4+* IDEAS
5.5+** TODO shed
5.6+:PROPERTIES:
5.7+:ID: fc9a94e1-91c5-4915-90b8-73218fa3b8bc
5.8+:END:
5.9+:LOGBOOK:
5.10+- State "TODO" from [2023-04-07 Fri 23:24]
5.11+:END:
5.12+rlib
5.13+> ulib
5.14+> ulib
5.15+> ulib
5.16+> ulib
5.17+
5.18+*** TODO sh* tools
5.19+:PROPERTIES:
5.20+:ID: c0613a13-7ccb-4af9-b47e-e14a41c782c2
5.21+:END:
5.22+:LOGBOOK:
5.23+- State "TODO" from "TODO" [2023-04-07 Fri 23:22]
5.24+:END:
5.25+shc,shx,etc
5.26+** WIP packy
5.27+:LOGBOOK:
5.28+- State "TODO" from [2023-04-07 Fri 23:33]
5.29+:END:
5.30+*** WIP rust
5.31+*** WIP common-lisp
5.32+*** WIP emacs-lisp
5.33+*** python
5.34+*** julia
5.35+*** C
5.36+*** C++
5.37+** TODO tenex
5.38+:LOGBOOK:
5.39+- State "TODO" from [2023-04-07 Fri 23:52]
5.40+:END:
5.41+** TODO mpk
5.42+:LOGBOOK:
5.43+- State "TODO" from [2023-04-07 Fri 23:52]
5.44+:END:
5.45+** TODO cfg
5.46+:LOGBOOK:
5.47+- State "TODO" from [2023-04-07 Fri 23:34]
5.48+:END:
5.49+** TODO obj
5.50+:LOGBOOK:
5.51+- State "TODO" from [2023-04-07 Fri 23:51]
5.52+:END:
5.53+split out from rlib to separate package
5.54+- a purely OOP class library
5.55+** TODO lab
5.56+:LOGBOOK:
5.57+- State "TODO" from [2023-04-07 Fri 23:34]
5.58+:END:
5.59+** TODO source categories
5.60+- need a way of extracting metadata from a repo
5.61+- need ability to search and query libs/packages
5.62+- separate modules based on where they belong in our stack?
5.63+ - app
5.64+ - lib
5.65+ - script?
5.66+ - dist
5.67+ - software distros
5.68+** TODO generic query language
5.69+from obj protocol?
5.70+sql compatibility?
5.71+
5.72+/check out kdb/
5.73+** TODO bbdb
5.74+:LOGBOOK:
5.75+- Note taken on [2023-10-24 Tue 22:16] \\
5.76+ graph database, build on rocksdb
5.77+:END:
5.78+insidious Big Brother database.
5.79+- an application built with obj
5.80+- sql
5.81+
5.82+** TODO NAS-TV :nas:t:
5.83+- media streaming
5.84+- gstreamer backend
5.85+- audio/video
6.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
6.2+++ b/notes/20231105.org Fri Nov 24 22:39:07 2023 -0500
6.3@@ -0,0 +1,136 @@
6.4+* DRAFT dylib-skel-1
6.5+- State "DRAFT" from [2023-11-05 Sun 22:23]
6.6+** Overview
6.7+Our core languages are [[https://www.rust-lang.org/][Rust]] and [[https://lisp-lang.org/][Lisp]] - this is the killer combo which will allow NAS-T
6.8+to rapidly develop high-quality software. As such, it's crucial that these two very
6.9+different languages (i.e. compilers) are able to interoperate seamlessly.
6.10+
6.11+Some interop methods are easy to accomodate via the OS - such as IPC or data sharing,
6.12+but others are a bit more difficult.
6.13+
6.14+In this 2-part series we'll build a FFI bridge between Rust and Lisp, which is something
6.15+that /can/ be difficult, due to some complications with Rust and because this is not the
6.16+most popular software stack (yet ;). This is an experiment and may not make it to our
6.17+code-base, but it's definitely something worth adding to the toolbox in case we need it.
6.18+
6.19+** FFI
6.20+The level of interop we're after in this case is [[https://en.wikipedia.org/wiki/Foreign_function_interface][FFI]].
6.21+
6.22+Basically, calling Rust code from Lisp and vice-versa. There's an article about calling
6.23+Rust from Common Lisp [[https://dev.to/veer66/calling-rust-from-common-lisp-45c5][here]] which shows the basics and serves as a great starting point
6.24+for those interested.
6.25+*** Rust != C
6.26+The complication(s) with Rust I mentioned early is really just that /it is not C/. =C=
6.27+is old, i.e. well-supported with a stable ABI, making the process of creating bindings
6.28+for a C library a breeze in many languages.
6.29+
6.30+For a Rust library we need to first appease the compiler, as explained in [[https://doc.rust-lang.org/nomicon/ffi.html#calling-rust-code-from-c][this section]]
6.31+of the Rustonomicon. Among other things it involves changing the calling-convention of
6.32+functions with a type signature and editing the Cargo.toml file to produce a
6.33+C-compatible ABI binary. The Rust default ABI is unstable and can't reliably be used
6.34+like the C ABI can.
6.35+
6.36+*** Overhead
6.37+Using FFI involves some overhead. Check [[https://github.com/dyu/ffi-overhead][here]] for an example benchmark across a few
6.38+languages. While building the NAS-T core, I'm very much aware of this, and will need a
6.39+few sanity benchmarks to make sure the cost doesn't outweigh the benefit. In particular,
6.40+I'm concerned about crossing multiple language barriers (Rust<->C<->Lisp).
6.41+
6.42+** Rust -> C -> Lisp
6.43+*** Setup
6.44+For starters, I'm going to assume we all have Rust (via =rustup=) and Lisp (=sbcl= only)
6.45+installed on our GNU/Linux system (some tweaks needed for Darwin/Windows, not covered in
6.46+this post).
6.47+**** Cargo
6.48+Create a new library crate. For this example we're focusing on a 'skeleton' for
6.49+/dynamic/ libraries only, so our experiment will be called =dylib-skel= or *dysk* for
6.50+short.
6.51+src_sh[:exports code]{cargo init dysk --lib && cd dysk}
6.52+
6.53+A =src/lib.rs= will be generated for you. Go ahead and delete that. We're going to be
6.54+making our own =lib.rs= file directly in the root directory (just to be cool).
6.55+
6.56+The next step is to edit your =Cargo.toml= file. Add these lines after the =[package]=
6.57+section and before =[dependencies]=:
6.58+#+begin_src conf-toml
6.59+[lib]
6.60+crate-type = ["cdylib","rlib"]
6.61+path = "lib.rs"
6.62+[[bin]]
6.63+name="dysk-test"
6.64+path="test.rs"
6.65+#+end_src
6.66+
6.67+This tells Rust to generate a shared C-compatible object with a =.so= extension which we
6.68+can open using [[https://man.archlinux.org/man/dlopen.3.en][dlopen]].
6.69+**** cbindgen
6.70+***** install
6.71+Next, we want the =cbindgen= program which we'll use to generate header files for
6.72+C/C++. This step isn't necessary at all, we just want it for further experimentation.
6.73+
6.74+src_sh[:exports code]{cargo install --force cbindgen}
6.75+
6.76+We append the =cbindgen= crate as a /build dependency/ to our =Cargo.toml= like so:
6.77+#+begin_src conf-toml
6.78+[build-dependencies]
6.79+cbindgen = "0.24"
6.80+#+end_src
6.81+***** cbindgen.toml
6.82+#+begin_src conf-toml :tangle cbindgen.toml
6.83+language = "C"
6.84+autogen_warning = "/* Warning, this file is autogenerated by cbindgen. Don't modify this manually. */"
6.85+include_version = true
6.86+namespace = "dysk"
6.87+cpp_compat = true
6.88+after_includes = "#define DYSK_VERSION \"0.1.0\""
6.89+line_length = 88
6.90+tab_width = 2
6.91+documentation = true
6.92+documentation_style = "c99"
6.93+usize_is_size_t = true
6.94+[cython]
6.95+header = '"dysk.h"'
6.96+#+end_src
6.97+***** build.rs
6.98+#+begin_src rust :tangle build.rs
6.99+fn main() -> Result<(), cbindgen::Error> {
6.100+ if let Ok(b) = cbindgen::generate(std::env::var("CARGO_MANIFEST_DIR").unwrap()) {
6.101+ b.write_to_file("dysk.h"); Ok(())}
6.102+ else { panic!("failed to generate dysk.h from cbindgen.toml") } }
6.103+#+end_src
6.104+*** lib.rs
6.105+#+begin_src rust :tangle lib.rs
6.106+//! lib.rs --- dysk library
6.107+use std::ffi::{c_char, c_int, CString};
6.108+#[no_mangle]
6.109+pub extern "C" fn dysk_hello() -> *const c_char {
6.110+ CString::new("hello from rust").unwrap().into_raw()}
6.111+#[no_mangle]
6.112+pub extern "C" fn dysk_plus(a:c_int,b:c_int) -> c_int {a+b}
6.113+#[no_mangle]
6.114+pub extern "C" fn dysk_plus1(n:c_int) -> c_int {n+1}
6.115+#+end_src
6.116+*** test.rs
6.117+#+begin_src rust :tangle test.rs
6.118+//! test.rs --- dysk test
6.119+fn main() { let mut i = 0u32; while i < 500000000 {i+=1; dysk::dysk_plus1(2 as core::ffi::c_int);}}
6.120+#+end_src
6.121+*** compile
6.122+#+begin_src sh
6.123+cargo build --release
6.124+#+end_src
6.125+*** load from SBCL
6.126+#+begin_src lisp :tangle dysk.lisp
6.127+(load-shared-object #P"target/release/libdysk.so")
6.128+(define-alien-routine dysk-hello c-string)
6.129+(define-alien-routine dysk-plus int (a int) (b int))
6.130+(define-alien-routine dysk-plus1 int (n int))
6.131+(dysk-hello) ;; => "hello from rust"
6.132+#+end_src
6.133+*** benchmark
6.134+#+begin_src shell
6.135+time target/release/dysk-test
6.136+#+end_src
6.137+#+begin_src lisp :tangle test.lisp
6.138+(time (dotimes (_ 500000000) (dysk-plus1 2)))
6.139+#+end_src
7.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
7.2+++ b/notes/20231124.org Fri Nov 24 22:39:07 2023 -0500
7.3@@ -0,0 +1,33 @@
7.4+* cl-dot examples
7.5+#+begin_src lisp
7.6+(defmethod cl-dot:graph-object-node ((graph (eql 'example)) (object cons))
7.7+ (make-instance 'cl-dot:node
7.8+ :attributes '(:label "cell \\N"
7.9+ :shape :box)))
7.10+(defmethod cl-dot:graph-object-points-to ((graph (eql 'example)) (object cons))
7.11+ (list (car object)
7.12+ (make-instance 'cl-dot:attributed
7.13+ :object (cdr object)
7.14+ :attributes '(:weight 3))))
7.15+;; Symbols
7.16+(defmethod cl-dot:graph-object-node ((graph (eql 'example)) (object symbol))
7.17+ (make-instance 'cl-dot:node
7.18+ :attributes `(:label ,object
7.19+ :shape :hexagon
7.20+ :style :filled
7.21+ :color :black
7.22+ :fillcolor "#ccccff")))
7.23+(let* ((data '(a b c #1=(b z) c d #1#))
7.24+ (dgraph (cl-dot:generate-graph-from-roots 'example (list data)
7.25+ '(:rankdir "LR" :layout "twopi" :labelloc "t"))))
7.26+ (cl-dot:dot-graph dgraph "test-lr.svg" :format #+nil :x11 :svg))
7.27+#+end_src
7.28+
7.29+#+RESULTS:
7.30+
7.31+#+begin_src lisp
7.32+(let* ((data '(a b))
7.33+ (dgraph (cl-dot:generate-graph-from-roots 'example (list data)
7.34+ '(:rankdir "LR"))))
7.35+ (cl-dot:print-graph dgraph))
7.36+#+end_src
8.1--- /dev/null Thu Jan 01 00:00:00 1970 +0000
8.2+++ b/notes/refs.bib Fri Nov 24 22:39:07 2023 -0500
8.3@@ -0,0 +1,169 @@
8.4+@article{btrfs,
8.5+author = {Rodeh, Ohad and Bacik, Josef and Mason, Chris},
8.6+year = {2013},
8.7+month = {08},
8.8+pages = {},
8.9+title = {BTRFS: The linux B-tree filesystem},
8.10+volume = {9},
8.11+journal = {ACM Transactions on Storage (TOS)},
8.12+doi = {10.1145/2501620.2501623}
8.13+}
8.14+@INPROCEEDINGS{zfs,
8.15+ author={Rodeh, O. and Teperman, A.},
8.16+ booktitle={20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies, 2003. (MSST 2003). Proceedings.},
8.17+ title={zFS - a scalable distributed file system using object disks},
8.18+ year={2003},
8.19+ volume={},
8.20+ number={},
8.21+ pages={207-218},
8.22+ doi={10.1109/MASS.2003.1194858}}
8.23+
8.24+@inproceedings{tmpfs,
8.25+ title={tmpfs: A Virtual Memory File System},
8.26+ author={Peter Snyder},
8.27+ year={1990},
8.28+ url={https://api.semanticscholar.org/CorpusID:54156693}
8.29+}
8.30+
8.31+@Article{nvme-ssd-ux,
8.32+AUTHOR = {Kim, Seongmin and Kim, Kyusik and Shin, Heeyoung and Kim, Taeseok},
8.33+TITLE = {Practical Enhancement of User Experience in NVMe SSDs},
8.34+JOURNAL = {Applied Sciences},
8.35+VOLUME = {10},
8.36+YEAR = {2020},
8.37+NUMBER = {14},
8.38+ARTICLE-NUMBER = {4765},
8.39+URL = {https://www.mdpi.com/2076-3417/10/14/4765},
8.40+ISSN = {2076-3417},
8.41+DOI = {10.3390/app10144765}
8.42+}
8.43+
8.44+@inproceedings{ext4,
8.45+author = {Djordjevic, Borislav and Timcenko, Valentina},
8.46+title = {Ext4 File System Performance Analysis in Linux Environment},
8.47+year = {2011},
8.48+isbn = {9781618040282},
8.49+publisher = {World Scientific and Engineering Academy and Society (WSEAS)},
8.50+address = {Stevens Point, Wisconsin, USA},
8.51+booktitle = {Proceedings of the 11th WSEAS International Conference on Applied Informatics and Communications, and Proceedings of the 4th WSEAS International Conference on Biomedical Electronics and Biomedical Informatics, and Proceedings of the International Conference on Computational Engineering in Systems Applications},
8.52+pages = {288–293},
8.53+numpages = {6},
8.54+keywords = {Linux, journaling, ext4/ext3/ext2, filesystems, inodes, disk performances, file block allocation},
8.55+location = {Florence, Italy},
8.56+series = {AIASABEBI'11}
8.57+}
8.58+
8.59+@Article{hd-failure-ml,
8.60+AUTHOR = {Zhang, Mingyu and Ge, Wenqiang and Tang, Ruichun and Liu, Peishun},
8.61+TITLE = {Hard Disk Failure Prediction Based on Blending Ensemble Learning},
8.62+JOURNAL = {Applied Sciences},
8.63+VOLUME = {13},
8.64+YEAR = {2023},
8.65+NUMBER = {5},
8.66+ARTICLE-NUMBER = {3288},
8.67+URL = {https://www.mdpi.com/2076-3417/13/5/3288},
8.68+ISSN = {2076-3417},
8.69+DOI = {10.3390/app13053288}
8.70+}
8.71+
8.72+@inproceedings{smart-ssd-qp,
8.73+author = {Do, Jaeyoung and Kee, Yang-Suk and Patel, Jignesh M. and Park, Chanik and Park, Kwanghyun and DeWitt, David J.},
8.74+title = {Query Processing on Smart SSDs: Opportunities and Challenges},
8.75+year = {2013},
8.76+isbn = {9781450320375},
8.77+publisher = {Association for Computing Machinery},
8.78+address = {New York, NY, USA},
8.79+url = {https://doi.org/10.1145/2463676.2465295},
8.80+doi = {10.1145/2463676.2465295},
8.81+booktitle = {Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data},
8.82+pages = {1221–1230},
8.83+numpages = {10},
8.84+keywords = {smart ssd},
8.85+location = {New York, New York, USA},
8.86+series = {SIGMOD '13}
8.87+}
8.88+
8.89+@inproceedings{ssd-perf-opt,
8.90+author = {Zuck, Aviad and G\"{u}hring, Philipp and Zhang, Tao and Porter, Donald E. and Tsafrir, Dan},
8.91+title = {Why and How to Increase SSD Performance Transparency},
8.92+year = {2019},
8.93+isbn = {9781450367271},
8.94+publisher = {Association for Computing Machinery},
8.95+address = {New York, NY, USA},
8.96+url = {https://doi.org/10.1145/3317550.3321430},
8.97+doi = {10.1145/3317550.3321430},
8.98+booktitle = {Proceedings of the Workshop on Hot Topics in Operating Systems},
8.99+pages = {192–200},
8.100+numpages = {9},
8.101+location = {Bertinoro, Italy},
8.102+series = {HotOS '19}
8.103+}
8.104+
8.105+@article{flash-openssd-systems,
8.106+author = {Kwak, Jaewook and Lee, Sangjin and Park, Kibin and Jeong, Jinwoo and Song, Yong Ho},
8.107+title = {Cosmos+ OpenSSD: Rapid Prototype for Flash Storage Systems},
8.108+year = {2020},
8.109+issue_date = {August 2020},
8.110+publisher = {Association for Computing Machinery},
8.111+address = {New York, NY, USA},
8.112+volume = {16},
8.113+number = {3},
8.114+issn = {1553-3077},
8.115+url = {https://doi.org/10.1145/3385073},
8.116+doi = {10.1145/3385073},
8.117+journal = {ACM Trans. Storage},
8.118+month = {jul},
8.119+articleno = {15},
8.120+numpages = {35},
8.121+keywords = {storage system, solid state drive (SSD), flash translation layer (FTL), Flash memory}
8.122+}
8.123+
8.124+@INPROCEEDINGS{emmc-mobile-io,
8.125+ author={Zhou, Deng and Pan, Wen and Wang, Wei and Xie, Tao},
8.126+ booktitle={2015 IEEE International Symposium on Workload Characterization},
8.127+ title={I/O Characteristics of Smartphone Applications and Their Implications for eMMC Design},
8.128+ year={2015},
8.129+ volume={},
8.130+ number={},
8.131+ pages={12-21},
8.132+ doi={10.1109/IISWC.2015.8}}
8.133+
8.134+@inproceedings{xfs-scalability,
8.135+ author = {Adam Sweeney and
8.136+ Doug Doucette and
8.137+ Wei Hu and
8.138+ Curtis Anderson and
8.139+ Mike Nishimoto and
8.140+ Geoff Peck},
8.141+ title = {Scalability in the {XFS} File System},
8.142+ booktitle = {Proceedings of the {USENIX} Annual Technical Conference, San Diego,
8.143+ California, USA, January 22-26, 1996},
8.144+ pages = {1--14},
8.145+ publisher = {{USENIX} Association},
8.146+ year = {1996},
8.147+ url = {http://www.usenix.org/publications/library/proceedings/sd96/sweeney.html},
8.148+ timestamp = {Wed, 04 Jul 2018 13:06:34 +0200},
8.149+ biburl = {https://dblp.org/rec/conf/usenix/Sweeney96.bib},
8.150+ bibsource = {dblp computer science bibliography, https://dblp.org}
8.151+}
8.152+
8.153+@inproceedings{xfs,
8.154+ title={xFS: A wide area mass storage file system},
8.155+ author={Wang, Randolph Y and Anderson, Thomas E},
8.156+ booktitle={Proceedings of IEEE 4th Workshop on Workstation Operating Systems. WWOS-III},
8.157+ pages={71--78},
8.158+ year={1993},
8.159+ organization={IEEE}
8.160+}
8.161+
8.162+@inproceedings {zns-usenix,
8.163+author = {Matias Bj{\o}rling and Abutalib Aghayev and Hans Holmberg and Aravind Ramesh and Damien Le Moal and Gregory R. Ganger and George Amvrosiadis},
8.164+title = {{ZNS}: Avoiding the Block Interface Tax for Flash-based {SSDs}},
8.165+booktitle = {2021 USENIX Annual Technical Conference (USENIX ATC 21)},
8.166+year = {2021},
8.167+isbn = {978-1-939133-23-6},
8.168+pages = {689--703},
8.169+url = {https://www.usenix.org/conference/atc21/presentation/bjorling},
8.170+publisher = {USENIX Association},
8.171+month = jul,
8.172+}
8.173\ No newline at end of file
9.1--- a/pitch.org Mon Nov 20 21:13:44 2023 -0500
9.2+++ b/pitch.org Fri Nov 24 22:39:07 2023 -0500
9.3@@ -1,5 +1,4 @@
9.4-#+AUTHOR: Richard Westhaver <ellis@rwest.io>
9.5-#+OPTIONS: ^:nil toc:nil num:nil html-postamble:nil
9.6-#+HTML_HEAD: <link rel="stylesheet" href="https://fonts.xz.style/serve/inter.css"/>
9.7-#+HTML_HEAD: <link rel="stylesheet" type="text/css" href="https://packy.rwest.io/style/css/new.min.css"/>
9.8-#+HTML_HEAD: <link rel="stylesheet" type="text/css" href="https://packy.rwest.io/style/css/night.css"/>
9.9+{{{header(pitch,
9.10+Richard Westhaver,
9.11+ellis@rwest.io,
9.12+The Big Picture)}}}
10.1--- a/publish.el Mon Nov 20 21:13:44 2023 -0500
10.2+++ b/publish.el Fri Nov 24 22:39:07 2023 -0500
10.3@@ -24,7 +24,8 @@
10.4 org-html-validation-link nil
10.5 org-src-fontify-natively t
10.6 make-backup-files nil
10.7- debug-on-error t)
10.8+ debug-on-error t
10.9+ org-id-link-to-org-use-id t)
10.10
10.11 (setq org-publish-project-alist
10.12 `(("compiler.company" :components ("index" "blog" "docs"))
11.1--- a/readme.org Mon Nov 20 21:13:44 2023 -0500
11.2+++ b/readme.org Fri Nov 24 22:39:07 2023 -0500
11.3@@ -11,7 +11,6 @@
11.4
11.5 - [[file:blog][blog]]
11.6 - [2023-11-19 Sun] [[https://compiler.company/blog/hello-world][hello-world]]
11.7-
11.8 - [[file:docs][docs]]
11.9 - [[file:roadmap.org][roadmap]]
11.10 - [[file:pitch.org][pitch]]
12.1--- a/roadmap.org Mon Nov 20 21:13:44 2023 -0500
12.2+++ b/roadmap.org Fri Nov 24 22:39:07 2023 -0500
12.3@@ -1,11 +1,7 @@
12.4-#+TITLE: roadmap
12.5-#+AUTHOR: Richard Westhaver
12.6-#+EMAIL: ellis@rwest.io
12.7-#+OPTIONS: ^:nil toc:nil num:nil
12.8-#+HTML_HEAD: <link rel="stylesheet" href="https://fonts.xz.style/serve/inter.css"/>
12.9-#+HTML_HEAD: <link rel="stylesheet" type="text/css" href="https://packy.rwest.io/style/css/new.min.css"/>
12.10-#+HTML_HEAD: <link rel="stylesheet" type="text/css" href="https://packy.rwest.io/style/css/night.css"/>
12.11-
12.12+{{{header(roadmap,
12.13+Richard Westhaver,
12.14+ellis@rwest.io,
12.15+The Compiler Company Roadmap)}}}
12.16 * WIP 2023
12.17 SCHEDULED: <2023-01-01 Mon>--[2023-12-31 Tue]
12.18 - State "WIP" from [2023-11-05 Sun 21:47]
13.1--- a/scratch/20230730.org Mon Nov 20 21:13:44 2023 -0500
13.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
13.3@@ -1,36 +0,0 @@
13.4-* VC infrastructure
13.5-In heptapod we have a root group named =comp=, containg a variety of
13.6-subgroups. Some of these groups should be public, while others are
13.7-internal to comp members exclusively. Within each subgroup, we should
13.8-have the root group members automatically granted privileged access to
13.9-projects. This is relevant for the =startup= subgroup in particular,
13.10-where each project is potentially maintained by multiple non-root
13.11-contributors.
13.12-
13.13-We also need to consider how we will manage subrepos across the
13.14-organization. It is about time we start integrating HG bundles and
13.15-potentially mirrors. For our core VC pipeline we should have no
13.16-reliance on Git, but this may be difficult. It depends on the behavior
13.17-of HG bundles.
13.18-
13.19-Bookmarks/tags should be used for milestones in the root group and are
13.20-infrequent. They are more frequent in projects with a regular release
13.21-life-cycle.
13.22-* Approaching Webapps
13.23-I started poking around in the webapp space again so that I can launch
13.24-a landing page for NAS-T quickly. The Rust situation has improved
13.25-somewhat on the frontend side, and the axum backend stack is nice.
13.26-
13.27-This might seem like a lot of Rust and not a lot of Lisp, which it is,
13.28-but there's still room for Lisp wherever we need it. It mostly plays a
13.29-role in the backend, servicing the database and responding to requests
13.30-from the Rust edges. All of the important tests for the web APIs are
13.31-also written in Lisp. We will almost certainly use Lisp for all static
13.32-processing and HTML generation at compile-time.
13.33-
13.34-This I believe, is the appropriate way to integrate Lisp into a
13.35-cutting-edge web-app. You get the good parts of Lisp where you need
13.36-them (interactive debugging, dynamic language, REPL) and avoid the bad
13.37-parts (OOB optimization, RPS performance) in areas where the customer
13.38-would be impacted. In this domain, Lisp takes the form of a glue
13.39-rather than the bricks and mortar it sometimes appears to us as.
14.1--- a/scratch/20231024.org Mon Nov 20 21:13:44 2023 -0500
14.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
14.3@@ -1,59 +0,0 @@
14.4-* virt
14.5-** QEMU
14.6-** KVM
14.7-** Hyper-V
14.8-** Firecracker
14.9-** Docker
14.10-** Vagrant
14.11-** LXC
14.12-** LXD
14.13-** containerd
14.14-** systemd-nspawn
14.15-** VirtualBox
14.16-
14.17-* Concatenative
14.18-** Factor :factor:
14.19-- [2023-07-04 Tue]
14.20- Factor is a cool concatenative lang but unfortunately the C interface
14.21- (vm/master.h) no longer exists on the master branch.
14.22-** Joy :joy:
14.23-
14.24-*** https://hypercubed.github.io/joy/html/j02maf.html
14.25-
14.26-*** [[https://builds.openlogicproject.org/content/incompleteness/arithmetization-syntax/arithmetization-syntax.pdf][arithmetization of syntax]]
14.27-* Lisp :lisp:
14.28-These notes pertain to Lisp. More specifically, ANSI Common Lisp in
14.29-most places.
14.30-
14.31-- https://github.com/lispnik/iup/ - doesn't support MacOS yet, looks
14.32- cool though
14.33- - what we really need is wasm compiler.. TBD
14.34-* Rust
14.35-** Serde
14.36-- [2023-07-05 Wed] \\
14.37- important part of the Rust ecosystem, another dtolnay
14.38- contribution. If you want to program a /data/ format in the Rust
14.39- ecosystem, this is how you do it.
14.40-
14.41- The way it works is that you define some special structs, a
14.42- Serializer and a Deserializer which implement the Serialize and
14.43- Deserialize traits provided by serde, respectively.
14.44-
14.45- You can use these structs to provide your public API. The
14.46- conventional choice is public top-level functions like from-str
14.47- and to-string. That's it, your serialization library can now read and
14.48- write your data format as Rust data types.
14.49-
14.50- [[https://serde.rs/enum-representations.html][enum-representations]]
14.51- - the default behavior is an externally tagged representation (verbose)
14.52-
14.53- The docs use strings as core IO when implementing a custom format,
14.54- but the convention is to implement for T where T is bound by std::io
14.55- Read or Write trait. Then you can provide a more robust public API
14.56- (from_bytes, from_writer, etc).
14.57-* C
14.58-* CPP
14.59-* Nu
14.60-[[https://www.nushell.sh/][~]]
14.61-[[https://www.nushell.sh/cookbook/][cookbook]]
14.62-[[https://github.com/nushell/nu_scripts][nu_scripts]]
15.1--- a/scratch/20231101.org Mon Nov 20 21:13:44 2023 -0500
15.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
15.3@@ -1,18 +0,0 @@
15.4-* AWS usage
15.5-We're leveraging AWS for some of our public web servers for now. It's
15.6-really not realistic to expect that my home desktop and spotty Comcast
15.7-internet can serve any production workflow. What it /is/ capable of is
15.8-a private VPN, which can communicate with AWS and other cloud VPN
15.9-depots via WireGuard ([[https://dev.to/gabrieltetzner/setting-up-a-vpn-with-wireguard-server-on-aws-ec2-4a49][article]]).
15.10-
15.11-I currently use Google Domains for nas-t.net, otom8.dev, and
15.12-rwest.io - but that business is now owned by squarespace, so I would
15.13-rather move it to Route53.
15.14-
15.15-We have archlinux ec2 image builds [[https://wiki.archlinux.org/title/Arch_Linux_AMIs_for_Amazon_Web_Services][here]] and [[https://gitlab.com/anemos-io/archlinux-ec2][here]] - only half work and not
15.16-maintained, but it's a start. I'm not even sure if I should stick with
15.17-arch or cave and use Ubuntu or AWS Linux. We can serve the static
15.18-services with little cost, the only big spender will be the heptapod
15.19-instance which requires a larger instance and some workers.
15.20-
15.21-We'll try to keep the cost at or around $30/month.
16.1--- a/scratch/20231102.org Mon Nov 20 21:13:44 2023 -0500
16.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
16.3@@ -1,82 +0,0 @@
16.4-* IDEAS
16.5-** TODO shed
16.6-:PROPERTIES:
16.7-:ID: fc9a94e1-91c5-4915-90b8-73218fa3b8bc
16.8-:END:
16.9-:LOGBOOK:
16.10-- State "TODO" from [2023-04-07 Fri 23:24]
16.11-:END:
16.12-rlib
16.13-> ulib
16.14-> ulib
16.15-> ulib
16.16-> ulib
16.17-
16.18-*** TODO sh* tools
16.19-:PROPERTIES:
16.20-:ID: c0613a13-7ccb-4af9-b47e-e14a41c782c2
16.21-:END:
16.22-:LOGBOOK:
16.23-- State "TODO" from "TODO" [2023-04-07 Fri 23:22]
16.24-:END:
16.25-shc,shx,etc
16.26-** WIP packy
16.27-:LOGBOOK:
16.28-- State "TODO" from [2023-04-07 Fri 23:33]
16.29-:END:
16.30-*** WIP rust
16.31-*** WIP common-lisp
16.32-*** WIP emacs-lisp
16.33-*** python
16.34-*** julia
16.35-*** C
16.36-*** C++
16.37-** TODO tenex
16.38-:LOGBOOK:
16.39-- State "TODO" from [2023-04-07 Fri 23:52]
16.40-:END:
16.41-** TODO mpk
16.42-:LOGBOOK:
16.43-- State "TODO" from [2023-04-07 Fri 23:52]
16.44-:END:
16.45-** TODO cfg
16.46-:LOGBOOK:
16.47-- State "TODO" from [2023-04-07 Fri 23:34]
16.48-:END:
16.49-** TODO obj
16.50-:LOGBOOK:
16.51-- State "TODO" from [2023-04-07 Fri 23:51]
16.52-:END:
16.53-split out from rlib to separate package
16.54-- a purely OOP class library
16.55-** TODO lab
16.56-:LOGBOOK:
16.57-- State "TODO" from [2023-04-07 Fri 23:34]
16.58-:END:
16.59-** TODO source categories
16.60-- need a way of extracting metadata from a repo
16.61-- need ability to search and query libs/packages
16.62-- separate modules based on where they belong in our stack?
16.63- - app
16.64- - lib
16.65- - script?
16.66- - dist
16.67- - software distros
16.68-** TODO generic query language
16.69-from obj protocol?
16.70-sql compatibility?
16.71-
16.72-/check out kdb/
16.73-** TODO bbdb
16.74-:LOGBOOK:
16.75-- Note taken on [2023-10-24 Tue 22:16] \\
16.76- graph database, build on rocksdb
16.77-:END:
16.78-insidious Big Brother database.
16.79-- an application built with obj
16.80-- sql
16.81-
16.82-** TODO NAS-TV :nas:t:
16.83-- media streaming
16.84-- gstreamer backend
16.85-- audio/video
17.1--- a/scratch/20231105.org Mon Nov 20 21:13:44 2023 -0500
17.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
17.3@@ -1,136 +0,0 @@
17.4-* DRAFT dylib-skel-1
17.5-- State "DRAFT" from [2023-11-05 Sun 22:23]
17.6-** Overview
17.7-Our core languages are [[https://www.rust-lang.org/][Rust]] and [[https://lisp-lang.org/][Lisp]] - this is the killer combo which will allow NAS-T
17.8-to rapidly develop high-quality software. As such, it's crucial that these two very
17.9-different languages (i.e. compilers) are able to interoperate seamlessly.
17.10-
17.11-Some interop methods are easy to accomodate via the OS - such as IPC or data sharing,
17.12-but others are a bit more difficult.
17.13-
17.14-In this 2-part series we'll build a FFI bridge between Rust and Lisp, which is something
17.15-that /can/ be difficult, due to some complications with Rust and because this is not the
17.16-most popular software stack (yet ;). This is an experiment and may not make it to our
17.17-code-base, but it's definitely something worth adding to the toolbox in case we need it.
17.18-
17.19-** FFI
17.20-The level of interop we're after in this case is [[https://en.wikipedia.org/wiki/Foreign_function_interface][FFI]].
17.21-
17.22-Basically, calling Rust code from Lisp and vice-versa. There's an article about calling
17.23-Rust from Common Lisp [[https://dev.to/veer66/calling-rust-from-common-lisp-45c5][here]] which shows the basics and serves as a great starting point
17.24-for those interested.
17.25-*** Rust != C
17.26-The complication(s) with Rust I mentioned early is really just that /it is not C/. =C=
17.27-is old, i.e. well-supported with a stable ABI, making the process of creating bindings
17.28-for a C library a breeze in many languages.
17.29-
17.30-For a Rust library we need to first appease the compiler, as explained in [[https://doc.rust-lang.org/nomicon/ffi.html#calling-rust-code-from-c][this section]]
17.31-of the Rustonomicon. Among other things it involves changing the calling-convention of
17.32-functions with a type signature and editing the Cargo.toml file to produce a
17.33-C-compatible ABI binary. The Rust default ABI is unstable and can't reliably be used
17.34-like the C ABI can.
17.35-
17.36-*** Overhead
17.37-Using FFI involves some overhead. Check [[https://github.com/dyu/ffi-overhead][here]] for an example benchmark across a few
17.38-languages. While building the NAS-T core, I'm very much aware of this, and will need a
17.39-few sanity benchmarks to make sure the cost doesn't outweigh the benefit. In particular,
17.40-I'm concerned about crossing multiple language barriers (Rust<->C<->Lisp).
17.41-
17.42-** Rust -> C -> Lisp
17.43-*** Setup
17.44-For starters, I'm going to assume we all have Rust (via =rustup=) and Lisp (=sbcl= only)
17.45-installed on our GNU/Linux system (some tweaks needed for Darwin/Windows, not covered in
17.46-this post).
17.47-**** Cargo
17.48-Create a new library crate. For this example we're focusing on a 'skeleton' for
17.49-/dynamic/ libraries only, so our experiment will be called =dylib-skel= or *dysk* for
17.50-short.
17.51-src_sh[:exports code]{cargo init dysk --lib && cd dysk}
17.52-
17.53-A =src/lib.rs= will be generated for you. Go ahead and delete that. We're going to be
17.54-making our own =lib.rs= file directly in the root directory (just to be cool).
17.55-
17.56-The next step is to edit your =Cargo.toml= file. Add these lines after the =[package]=
17.57-section and before =[dependencies]=:
17.58-#+begin_src conf-toml
17.59-[lib]
17.60-crate-type = ["cdylib","rlib"]
17.61-path = "lib.rs"
17.62-[[bin]]
17.63-name="dysk-test"
17.64-path="test.rs"
17.65-#+end_src
17.66-
17.67-This tells Rust to generate a shared C-compatible object with a =.so= extension which we
17.68-can open using [[https://man.archlinux.org/man/dlopen.3.en][dlopen]].
17.69-**** cbindgen
17.70-***** install
17.71-Next, we want the =cbindgen= program which we'll use to generate header files for
17.72-C/C++. This step isn't necessary at all, we just want it for further experimentation.
17.73-
17.74-src_sh[:exports code]{cargo install --force cbindgen}
17.75-
17.76-We append the =cbindgen= crate as a /build dependency/ to our =Cargo.toml= like so:
17.77-#+begin_src conf-toml
17.78-[build-dependencies]
17.79-cbindgen = "0.24"
17.80-#+end_src
17.81-***** cbindgen.toml
17.82-#+begin_src conf-toml :tangle cbindgen.toml
17.83-language = "C"
17.84-autogen_warning = "/* Warning, this file is autogenerated by cbindgen. Don't modify this manually. */"
17.85-include_version = true
17.86-namespace = "dysk"
17.87-cpp_compat = true
17.88-after_includes = "#define DYSK_VERSION \"0.1.0\""
17.89-line_length = 88
17.90-tab_width = 2
17.91-documentation = true
17.92-documentation_style = "c99"
17.93-usize_is_size_t = true
17.94-[cython]
17.95-header = '"dysk.h"'
17.96-#+end_src
17.97-***** build.rs
17.98-#+begin_src rust :tangle build.rs
17.99-fn main() -> Result<(), cbindgen::Error> {
17.100- if let Ok(b) = cbindgen::generate(std::env::var("CARGO_MANIFEST_DIR").unwrap()) {
17.101- b.write_to_file("dysk.h"); Ok(())}
17.102- else { panic!("failed to generate dysk.h from cbindgen.toml") } }
17.103-#+end_src
17.104-*** lib.rs
17.105-#+begin_src rust :tangle lib.rs
17.106-//! lib.rs --- dysk library
17.107-use std::ffi::{c_char, c_int, CString};
17.108-#[no_mangle]
17.109-pub extern "C" fn dysk_hello() -> *const c_char {
17.110- CString::new("hello from rust").unwrap().into_raw()}
17.111-#[no_mangle]
17.112-pub extern "C" fn dysk_plus(a:c_int,b:c_int) -> c_int {a+b}
17.113-#[no_mangle]
17.114-pub extern "C" fn dysk_plus1(n:c_int) -> c_int {n+1}
17.115-#+end_src
17.116-*** test.rs
17.117-#+begin_src rust :tangle test.rs
17.118-//! test.rs --- dysk test
17.119-fn main() { let mut i = 0u32; while i < 500000000 {i+=1; dysk::dysk_plus1(2 as core::ffi::c_int);}}
17.120-#+end_src
17.121-*** compile
17.122-#+begin_src sh
17.123-cargo build --release
17.124-#+end_src
17.125-*** load from SBCL
17.126-#+begin_src lisp :tangle dysk.lisp
17.127-(load-shared-object #P"target/release/libdysk.so")
17.128-(define-alien-routine dysk-hello c-string)
17.129-(define-alien-routine dysk-plus int (a int) (b int))
17.130-(define-alien-routine dysk-plus1 int (n int))
17.131-(dysk-hello) ;; => "hello from rust"
17.132-#+end_src
17.133-*** benchmark
17.134-#+begin_src shell
17.135-time target/release/dysk-test
17.136-#+end_src
17.137-#+begin_src lisp :tangle test.lisp
17.138-(time (dotimes (_ 500000000) (dysk-plus1 2)))
17.139-#+end_src
18.1--- a/scratch/refs.bib Mon Nov 20 21:13:44 2023 -0500
18.2+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
18.3@@ -1,169 +0,0 @@
18.4-@article{btrfs,
18.5-author = {Rodeh, Ohad and Bacik, Josef and Mason, Chris},
18.6-year = {2013},
18.7-month = {08},
18.8-pages = {},
18.9-title = {BTRFS: The linux B-tree filesystem},
18.10-volume = {9},
18.11-journal = {ACM Transactions on Storage (TOS)},
18.12-doi = {10.1145/2501620.2501623}
18.13-}
18.14-@INPROCEEDINGS{zfs,
18.15- author={Rodeh, O. and Teperman, A.},
18.16- booktitle={20th IEEE/11th NASA Goddard Conference on Mass Storage Systems and Technologies, 2003. (MSST 2003). Proceedings.},
18.17- title={zFS - a scalable distributed file system using object disks},
18.18- year={2003},
18.19- volume={},
18.20- number={},
18.21- pages={207-218},
18.22- doi={10.1109/MASS.2003.1194858}}
18.23-
18.24-@inproceedings{tmpfs,
18.25- title={tmpfs: A Virtual Memory File System},
18.26- author={Peter Snyder},
18.27- year={1990},
18.28- url={https://api.semanticscholar.org/CorpusID:54156693}
18.29-}
18.30-
18.31-@Article{nvme-ssd-ux,
18.32-AUTHOR = {Kim, Seongmin and Kim, Kyusik and Shin, Heeyoung and Kim, Taeseok},
18.33-TITLE = {Practical Enhancement of User Experience in NVMe SSDs},
18.34-JOURNAL = {Applied Sciences},
18.35-VOLUME = {10},
18.36-YEAR = {2020},
18.37-NUMBER = {14},
18.38-ARTICLE-NUMBER = {4765},
18.39-URL = {https://www.mdpi.com/2076-3417/10/14/4765},
18.40-ISSN = {2076-3417},
18.41-DOI = {10.3390/app10144765}
18.42-}
18.43-
18.44-@inproceedings{ext4,
18.45-author = {Djordjevic, Borislav and Timcenko, Valentina},
18.46-title = {Ext4 File System Performance Analysis in Linux Environment},
18.47-year = {2011},
18.48-isbn = {9781618040282},
18.49-publisher = {World Scientific and Engineering Academy and Society (WSEAS)},
18.50-address = {Stevens Point, Wisconsin, USA},
18.51-booktitle = {Proceedings of the 11th WSEAS International Conference on Applied Informatics and Communications, and Proceedings of the 4th WSEAS International Conference on Biomedical Electronics and Biomedical Informatics, and Proceedings of the International Conference on Computational Engineering in Systems Applications},
18.52-pages = {288–293},
18.53-numpages = {6},
18.54-keywords = {Linux, journaling, ext4/ext3/ext2, filesystems, inodes, disk performances, file block allocation},
18.55-location = {Florence, Italy},
18.56-series = {AIASABEBI'11}
18.57-}
18.58-
18.59-@Article{hd-failure-ml,
18.60-AUTHOR = {Zhang, Mingyu and Ge, Wenqiang and Tang, Ruichun and Liu, Peishun},
18.61-TITLE = {Hard Disk Failure Prediction Based on Blending Ensemble Learning},
18.62-JOURNAL = {Applied Sciences},
18.63-VOLUME = {13},
18.64-YEAR = {2023},
18.65-NUMBER = {5},
18.66-ARTICLE-NUMBER = {3288},
18.67-URL = {https://www.mdpi.com/2076-3417/13/5/3288},
18.68-ISSN = {2076-3417},
18.69-DOI = {10.3390/app13053288}
18.70-}
18.71-
18.72-@inproceedings{smart-ssd-qp,
18.73-author = {Do, Jaeyoung and Kee, Yang-Suk and Patel, Jignesh M. and Park, Chanik and Park, Kwanghyun and DeWitt, David J.},
18.74-title = {Query Processing on Smart SSDs: Opportunities and Challenges},
18.75-year = {2013},
18.76-isbn = {9781450320375},
18.77-publisher = {Association for Computing Machinery},
18.78-address = {New York, NY, USA},
18.79-url = {https://doi.org/10.1145/2463676.2465295},
18.80-doi = {10.1145/2463676.2465295},
18.81-booktitle = {Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data},
18.82-pages = {1221–1230},
18.83-numpages = {10},
18.84-keywords = {smart ssd},
18.85-location = {New York, New York, USA},
18.86-series = {SIGMOD '13}
18.87-}
18.88-
18.89-@inproceedings{ssd-perf-opt,
18.90-author = {Zuck, Aviad and G\"{u}hring, Philipp and Zhang, Tao and Porter, Donald E. and Tsafrir, Dan},
18.91-title = {Why and How to Increase SSD Performance Transparency},
18.92-year = {2019},
18.93-isbn = {9781450367271},
18.94-publisher = {Association for Computing Machinery},
18.95-address = {New York, NY, USA},
18.96-url = {https://doi.org/10.1145/3317550.3321430},
18.97-doi = {10.1145/3317550.3321430},
18.98-booktitle = {Proceedings of the Workshop on Hot Topics in Operating Systems},
18.99-pages = {192–200},
18.100-numpages = {9},
18.101-location = {Bertinoro, Italy},
18.102-series = {HotOS '19}
18.103-}
18.104-
18.105-@article{flash-openssd-systems,
18.106-author = {Kwak, Jaewook and Lee, Sangjin and Park, Kibin and Jeong, Jinwoo and Song, Yong Ho},
18.107-title = {Cosmos+ OpenSSD: Rapid Prototype for Flash Storage Systems},
18.108-year = {2020},
18.109-issue_date = {August 2020},
18.110-publisher = {Association for Computing Machinery},
18.111-address = {New York, NY, USA},
18.112-volume = {16},
18.113-number = {3},
18.114-issn = {1553-3077},
18.115-url = {https://doi.org/10.1145/3385073},
18.116-doi = {10.1145/3385073},
18.117-journal = {ACM Trans. Storage},
18.118-month = {jul},
18.119-articleno = {15},
18.120-numpages = {35},
18.121-keywords = {storage system, solid state drive (SSD), flash translation layer (FTL), Flash memory}
18.122-}
18.123-
18.124-@INPROCEEDINGS{emmc-mobile-io,
18.125- author={Zhou, Deng and Pan, Wen and Wang, Wei and Xie, Tao},
18.126- booktitle={2015 IEEE International Symposium on Workload Characterization},
18.127- title={I/O Characteristics of Smartphone Applications and Their Implications for eMMC Design},
18.128- year={2015},
18.129- volume={},
18.130- number={},
18.131- pages={12-21},
18.132- doi={10.1109/IISWC.2015.8}}
18.133-
18.134-@inproceedings{xfs-scalability,
18.135- author = {Adam Sweeney and
18.136- Doug Doucette and
18.137- Wei Hu and
18.138- Curtis Anderson and
18.139- Mike Nishimoto and
18.140- Geoff Peck},
18.141- title = {Scalability in the {XFS} File System},
18.142- booktitle = {Proceedings of the {USENIX} Annual Technical Conference, San Diego,
18.143- California, USA, January 22-26, 1996},
18.144- pages = {1--14},
18.145- publisher = {{USENIX} Association},
18.146- year = {1996},
18.147- url = {http://www.usenix.org/publications/library/proceedings/sd96/sweeney.html},
18.148- timestamp = {Wed, 04 Jul 2018 13:06:34 +0200},
18.149- biburl = {https://dblp.org/rec/conf/usenix/Sweeney96.bib},
18.150- bibsource = {dblp computer science bibliography, https://dblp.org}
18.151-}
18.152-
18.153-@inproceedings{xfs,
18.154- title={xFS: A wide area mass storage file system},
18.155- author={Wang, Randolph Y and Anderson, Thomas E},
18.156- booktitle={Proceedings of IEEE 4th Workshop on Workstation Operating Systems. WWOS-III},
18.157- pages={71--78},
18.158- year={1993},
18.159- organization={IEEE}
18.160-}
18.161-
18.162-@inproceedings {zns-usenix,
18.163-author = {Matias Bj{\o}rling and Abutalib Aghayev and Hans Holmberg and Aravind Ramesh and Damien Le Moal and Gregory R. Ganger and George Amvrosiadis},
18.164-title = {{ZNS}: Avoiding the Block Interface Tax for Flash-based {SSDs}},
18.165-booktitle = {2021 USENIX Annual Technical Conference (USENIX ATC 21)},
18.166-year = {2021},
18.167-isbn = {978-1-939133-23-6},
18.168-pages = {689--703},
18.169-url = {https://www.usenix.org/conference/atc21/presentation/bjorling},
18.170-publisher = {USENIX Association},
18.171-month = jul,
18.172-}
18.173\ No newline at end of file
