mirror of
https://github.com/RGBCube/Site
synced 2025-07-31 13:07:46 +00:00
Compare commits
10 commits
1b310ce652
...
03d1ef80ab
| Author | SHA1 | Date | |
|---|---|---|---|
03d1ef80ab
|
|||
|
a52b2f6001
|
|||
|
1116a3d797
|
|||
|
a765c5fadc
|
|||
|
ad7e1a12c1
|
|||
|
6f112dd0cd
|
|||
|
07e9881fe7
|
|||
|
985bf7e36f
|
|||
|
51db068f5f
|
|||
|
04f6b195f9
|
5 changed files with 116 additions and 19 deletions
|
|
@ -199,7 +199,8 @@ body {
|
|||
@apply wrap-anywhere;
|
||||
}
|
||||
|
||||
&:not(:has(> code:only-child), :has(> img)) {
|
||||
/* See next FIXME */
|
||||
&:not(/* :has(> code:only-child), */ :has(> img)) {
|
||||
@apply px-1;
|
||||
|
||||
&:not(.font-mono) {
|
||||
|
|
@ -211,9 +212,10 @@ body {
|
|||
@apply inline wrap-anywhere text-[red] dark:text-[yellow] border-2
|
||||
border-[transparent] border-dashed;
|
||||
|
||||
&:has(> code:only-child) {
|
||||
@apply border-dotted;
|
||||
}
|
||||
/* FIXME: :only-child still triggers when there is sibling raw content: <a>foo bar: <code>this is an only child</code></a> */
|
||||
/* &:has(> code:only-child) { */
|
||||
/* @apply border-dotted; */
|
||||
/* } */
|
||||
|
||||
&:hover {
|
||||
@apply border-[red] dark:border-[yellow];
|
||||
|
|
@ -258,10 +260,11 @@ body {
|
|||
code:not(pre > code) {
|
||||
@apply border-1 border-dotted px-2 py-0.5 border-black dark:border-white;
|
||||
|
||||
a:is(:hover, :active) /* TODO: :only-child selector doesn't have effect. */
|
||||
&:not(:where(h1, h2, h3, h4, h5, h6) code):only-child {
|
||||
@apply border-transparent;
|
||||
}
|
||||
/* See previous FIXME */
|
||||
/* a:is(:hover, :active) */
|
||||
/* &:not(:where(h1, h2, h3, h4, h5, h6) code):only-child { */
|
||||
/* @apply border-transparent; */
|
||||
/* } */
|
||||
}
|
||||
|
||||
pre code, pre code * {
|
||||
|
|
@ -308,8 +311,16 @@ body {
|
|||
}
|
||||
|
||||
blockquote {
|
||||
@apply border-1 p-2 bg-[#eee] shadow-[4px_4px_#444] dark:border-white
|
||||
dark:bg-[#111] dark:shadow-[4px_4px_#bbb];
|
||||
@apply border-1 border-black dark:border-white p-2 bg-[#eee]
|
||||
shadow-[4px_4px_#444] dark:bg-[#111] dark:shadow-[4px_4px_#bbb];
|
||||
}
|
||||
|
||||
details {
|
||||
& > summary {
|
||||
@apply inline-block border-4 border-double border-[red]
|
||||
hover:border-[maroon] dark:border-[yellow] dark:hover:border-[goldenrod]
|
||||
p-4 cursor-pointer;
|
||||
}
|
||||
}
|
||||
|
||||
.callout {
|
||||
|
|
|
|||
|
|
@ -262,7 +262,7 @@ than others. The process determines how faulty a CPU is and sorts them into
|
|||
higher tier CPUs exist.
|
||||
|
||||
The likelihood of faulty silicon also increases with the smaller the
|
||||
architecture size gets (the Apple M4 is 4m, which is crazy), so this method of
|
||||
architecture size gets (the Apple M4 is 4nm, which is crazy), so this method of
|
||||
recycling worse chips is becoming much more valuable by the day.
|
||||
|
||||
So, in summary the 32 core CPU I was testing this on was most likely just the 64
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Let's start from the top:
|
|||
</h2>
|
||||
|
||||
Cab doesn't have "declarations", or "pattern matching". This is a _literal_
|
||||
comparision operation. Exactly the same as the `==` operator in most languages.
|
||||
comparison operation. Exactly the same as the `==` operator in most languages.
|
||||
|
||||
But then, how do we even declare anything in the local scope? How do we address
|
||||
values by name, instead of inlining them all?
|
||||
|
|
@ -67,7 +67,7 @@ In Cab, you can create a binding value with the `@<identifier-here>` syntax. So
|
|||
here, `@Any` is a binding value.
|
||||
|
||||
And the way you use bindings (aka, binds) in Cab is simple: You compare them
|
||||
using the comparision operator, `=` or `!=`.
|
||||
using the comparison operator, `=` or `!=`.
|
||||
|
||||
A bind is equal to _any_ value, literally anything! So, `@foo = 123` is always
|
||||
true.
|
||||
|
|
@ -95,7 +95,7 @@ In order to prevent things from going out of control, Cab limits when binds can
|
|||
bind the value they are compared to to their local scope.
|
||||
|
||||
The rule that governs this is: A bind, when compared to a value, will bind that
|
||||
value to the scope the bind was declared in _if the comparision operation is
|
||||
value to the scope the bind was declared in _if the comparison operation is
|
||||
within that scope_.
|
||||
|
||||
So, we don't actually get `_` bound to `@Any` because the `=` is outside the
|
||||
|
|
@ -137,7 +137,7 @@ Trailing commas are nice!
|
|||
|
||||
</h1>
|
||||
|
||||
I've already explained how comparisions & binds work in Cab, so I'll skip the
|
||||
I've already explained how comparisons & binds work in Cab, so I'll skip the
|
||||
`@symbol =` part.
|
||||
|
||||
The way lambdas work in Cab is as follows: `<value> => <body>`.
|
||||
|
|
@ -146,8 +146,8 @@ The `=>` is an infix operator, yet again. And the `<value>` can be _any
|
|||
expression_.
|
||||
|
||||
When a lambda is called, the `<value>` is compared with the argument in a new
|
||||
scope. If they are not "equal", aka when the comparision evaluates to `false`,
|
||||
an exception is thrown.
|
||||
scope. If they are not "equal", aka when the comparison evaluates to `false`, an
|
||||
exception is thrown.
|
||||
|
||||
But when it is `true`, the `<body>` is evaluated and returned.
|
||||
|
||||
|
|
@ -172,7 +172,7 @@ What is `String`? It's a value that is equal to all strings. No, not exactly a
|
|||
"type"! This is why Cab doesn't exactly have "typing", as everything is a value.
|
||||
|
||||
This makes `@name & String` a value that is equal to any string, and when
|
||||
compared to a string value, will bind it to the scope & have the comparision
|
||||
compared to a string value, will bind it to the scope & have the comparison
|
||||
expression evaluate to `true`.
|
||||
|
||||
## The body
|
||||
|
|
|
|||
86
site/dump/posix/fsync-pitfalls.md
Normal file
86
site/dump/posix/fsync-pitfalls.md
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
title: "`fsync(2)` Pitfalls"
|
||||
date: 2025-07-11
|
||||
---
|
||||
|
||||
# `fsync` Pitfalls
|
||||
|
||||
This is a non-comprehensive list of the pitfalls of the `fsync` syscall.
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
|
||||
Linux `man 2 fsync`
|
||||
|
||||
</summary>
|
||||
|
||||
> `fsync()` transfers ("flushes") all modified in-core data of (i.e., modified
|
||||
> buffer cache pages for) the file referred to by the file descriptor fd to the
|
||||
> disk device (or other permanent storage device) so that all changed
|
||||
> information can be retrieved even if the system crashes or is rebooted. This
|
||||
> includes writing through or flushing a disk cache if present. The call blocks
|
||||
> until the device reports that the transfer has completed.
|
||||
>
|
||||
> As well as flushing the file data, `fsync()` also flushes the metadata
|
||||
> information associated with the file (see inode(7)).
|
||||
>
|
||||
> Calling `fsync()` does not necessarily ensure that the entry in the directory
|
||||
> containing the file has also reached disk. For that an explicit `fsync()` on a
|
||||
> file descriptor for the directory is also needed.
|
||||
>
|
||||
> `fdatasync()` is similar to `fsync()`, but does not flush modified metadata
|
||||
> unless that metadata is needed in order to allow a subsequent data retrieval
|
||||
> to be correctly handled. For example, changes to st_atime or st_mtime
|
||||
> (respectively, time of last access and time of last modification; see
|
||||
> inode(7)) do not require flushing because they are not necessary for a
|
||||
> subsequent data read to be handled correctly. On the other hand, a change to
|
||||
> the file size (st_size, as made by say ftruncate(2)), would require a metadata
|
||||
> flush.
|
||||
>
|
||||
> The aim of `fdatasync()` is to reduce disk activity for applications that do
|
||||
> not require all metadata to be synchronized with the disk.
|
||||
|
||||
</details>
|
||||
|
||||
I will expand this list as I have more questions about all the questionable
|
||||
filesystems used and created by operating system enthusiasts.
|
||||
|
||||
## `fsync` does not ensure that a `fsync`'d file is visible in its parent directory
|
||||
|
||||
From the manpage:
|
||||
|
||||
> Calling `fsync()` does not necessarily ensure that the entry in the directory
|
||||
> containing the file has also reached disk. For that an explicit `fsync()` on a
|
||||
> file descriptor for the directory is also needed.
|
||||
|
||||
This means that that you cannot rely on a file being in the directory after
|
||||
`fsync`ing the file itself. You have to `fsync` the directory too.
|
||||
|
||||
Speaking about `fsync`ing a directory:
|
||||
|
||||
## `fsync` on a directory does not ensure children are `fsync`'d
|
||||
|
||||
From the manpage:
|
||||
|
||||
> Calling `fsync()` does not necessarily ensure that the entry in the directory
|
||||
> containing the file has also reached disk. For that an explicit `fsync()` on a
|
||||
> file descriptor for the directory is also needed.
|
||||
|
||||
The assumption that `fsync` a directory will fsync the files themselves is also
|
||||
wrong. You can imagine a directory as a file containing a list of children, and
|
||||
the list is just pointers to inodes. So `fsync`ing a directory will just write
|
||||
the list of pointers to disk.
|
||||
|
||||
## More reading on `fsync` and other things related to files
|
||||
|
||||
- [(danluu) Fsyncgate: Errors on `fsync` are unrecoverable](https://danluu.com/fsyncgate/)
|
||||
- [(danluu) Files are hard](https://danluu.com/file-consistency/)
|
||||
- [(puzpuzpuz) The secret life of `fsync`](https://puzpuzpuz.dev/the-secret-life-of-fsync)
|
||||
- [(stackoverflow) Difference between `syncfs` (Linux only) and `fsync` (POSIX)](https://stackoverflow.com/questions/48171855/what-is-the-difference-between-fsync-and-syncfs)
|
||||
(TL;DR: `syncfs` is "pretty please" fsync and doesn't block until the
|
||||
operation is done)
|
||||
- [(transactional.blog) Userland Disk I/O](https://transactional.blog/how-to-learn/disk-io)
|
||||
- [(LWN) Feathersticth: Killing `fsync` softly](https://lwn.net/Articles/354861/)
|
||||
- [(stackoverflow) Your Program ---~~`fflush`~~---> Your OS ---~~`fsync`~~---> Your Disk](https://stackoverflow.com/questions/2340610/difference-between-fflush-and-fsync)
|
||||
- [(despairlabs) `fsync()` after `open()` is an elaborate no-op](https://despairlabs.com/blog/posts/2025-03-13-fsync-after-open-is-an-elaborate-no-op/)
|
||||
- [(Postgres Wiki) `fsync` errors](https://wiki.postgresql.org/wiki/Fsync_Errors)
|
||||
|
|
@ -21,5 +21,5 @@ able to recall the HSTS header, and let you connect insecurely.
|
|||
> Do not do this if you value your browsing history of that site. It literally
|
||||
> says "Forget This Site", act accordingly.
|
||||
|
||||
These instrucitons are Firefox and Firefox-based browser specific, but the
|
||||
These instructions are Firefox and Firefox-based browser specific, but the
|
||||
process is same on other browsers.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue