grantwu

Isn't S3 Express not the same API? You have to use a "directory bucket" which isn't an object store anymore, as it has actual directories.

To be honest I'm not actually sure how different the API is. I've never used it. I just frequently trip over the existence of parallel APIs for directory buckets (when I'm doing something niche, mostly; I think GetObject/PutObject are the same.)

I haven't read "Changing Minds".

> As he points out: it would be terrible! We’d lose the intuitive understanding of how to use the gears to solve any situation we encounter. Which mode do you use for gravel + downhill?

I have no idea, actually, what gears I should use for gravel + downhill, which is surprising since about 6 years ago I biked from Pittsburgh to DC, which had a fairly long downhill section. I remember mostly coasting on that section. I might've stopped a few times to make sure my brakes could cool down. I don't think there is a wrong gear on a bicycle when coasting down on gravel?

Perhaps I am the user who does need a nightmare bicycle with a gravel + downhill button.

The timeline says that the initial report was 6/16 and the initial patches were 7/8 and 7/18.

It's not clear to me what was exploitable when.

I'm not following what you're saying. Why do we need a callback?

In this imaginary design, the syscalls you make would look something like:

- BeginChannelTx -> return ChannelTxID

- ReadZFSProperties(ChannelTxID, params) -> return data

- DestroySomeDatasets(ChannelTxID, params) -> ok

- CommitChannelTx(ChannelTxID)

Notably, DestroySomeDatasets doesn't actually do any work. It merely records which datasets you want to destroy. There are no callbacks as far as I can see: there's no kernel thread waiting on a user thread to do something. This way also lets you express branching.

The drawback of this approach is you need a lock on all mutating administrative commands when you call BeginChannelTX. I talked to a ZFS dev, and he said that with ZFS' design, that's actually the txg sync lock. This means that while reads will proceed, writes will only proceed for a short period of time, and nothing will make it to disk. The overhead of making all these syscalls was also judged to be problematic.

> Blocking within one, with those locks acquired, and thunking back down to userspace, would mean that 1. a CPU core, and 2. the filesystem itself, would both be tied up indefinitely until that callback thunk returns. If it ever does!

In this theoretical design, you could just block all other administrative modifications. I don't think you need to tie up an entire CPU core, and I'm fairly sure that these zfs operations don't block regular reads and writes.

I think you had it right in your initial comment. There's no good way express branching with an implementation which incrementally submits operations to be committed as a batch. You'd have to take an admin lock on an entire zpool.

EDIT: talked to a zfs dev, said this would take the txg sync lock.

Works as expected? Wouldn't that WHERE clause filter out all of the rows? Is that frequently desired behavior?

Can someone explain why Blastdoor has been unsuccessful? Is it too hard a problem to restrict what iMessage can do?

Where? CTRL-F Randen doesn't show anything, and the Randen repo claims it's faster than ChaCha8.

DevOps engineer link appears to 404.

Oh I guess we don't need maintenance then