Sure, adding that functionality to NVMe would be easy; there are sufficient provisions around for adding such support. E.g. for example a global flag who's support is communicated and which can then be turned on by the host to cause the very same normal flush opcode to now also guarantee a pipelined write barrier (while retaining the flush-write-back-caches-before-reporting-completion-of-this-submitted-IO-operation).
The reason it hadn't yet been supported btw. is that they explicitly wanted to allow fully parallel processing of commands in a queue, at least for submissions that concurrently exist in the command queue. In practice I don't see why this would have to be enforced to such an extend, as the only reason for out-of-order processing I can think of is that the auxiliary data of a command is physically located in host memory and the DMA reads across PCIe from the NVMe controller to the host memory happen to complete out-of-order for host DRAM controller/pattern reasons.
Thus it might be something you'd not want to turn on without using controller memory buffer (where you can mmap some of the DRAM on the NVMe device into host memory, write your full-detail commands directly to this across the PCIe, and keep the NVMe controller from having to first send a read request across PCIe in response to you ringing it's doorbell: instead it can directly read from it's local DRAM when you ring the doorbell).
I wish someone would sell an SSD that was at most a firmware update away between regular NVMe drive and ZNS NVMe drive.
The latter just doesn't leave much room for the firmware to be clever and just swallow data.
Maybe also add a pSLC formatting mode for a namespace so one can be explicit about that capability...
It just has to be a drive that's useable as a generic gaming SSD so people can just buy it and have casual fun with it, like they did with Nvidia GTX GPUs and CUDA.
Unfortunately manifacturers almost always prefer price gouging on features that "CuStOmErS aRe NoT GoInG tO nEeD". Is it even a ZNS device available for someone who isn't a hyperscale datacenter operator nowadays?
Either you ask a manufacturer like WD, or you go to ebay AFAIK.
That said, ZNS is actually something specifically about being able to extract more value out of the same hardware (as the firmware no longer causes write amplification behind your back), which in turns means that the value for such a ZNS-capable drive ought to be strictly higher than for the traditional-only version with the same hardware.
And given that enterprise SSDs seem to only really get value from an OEM's holographic sticker on them (compare almost-new-grade used prices for those with the sticker on them vs. the just plain SSD/HDD original model number, missing the premium sticker), besides the common write-back-emergency capacitors that allow a physical write-back cache in the drive to ("safely") claim write-through semantics to the host, it should IMO be in the interest of the manufacturers to push ZNS:
ZNS makes, for ZNS-appropriate applications, the exact same hardware perform better despite requiring less fancy firmware.
Also, especially, there's much less need for write-back cache as the drive doesn't sort individual random writes into something less prone to write amplification: the host software is responsible for sorting data together for minimizing write amplification (usually, arranging for data that will likely be deleted together to be physically in the same erasure block).
Also, I'm not sure how exactly "bad" bins of flash behave, but I'd not be surprised if ZNS's support for zones having less usable space than LBA/address range occupied (which can btw. change upon recycling/erasing the zone!) would allow rather poor quality flash to still be effectively utilized, as even rather unpredictable degradation can be handled this way.
Basically, due to Copy-on-Write storage systems (like, Btrfs or many modern database backends (specifically, LSM-Tree ones)) inherently needing some slack/empty space, it's rather easy to cope with this space decreasing as a result of write operations, regardless of if the application/user data has actually grown from the writes: you just buy and add another drive/cluster-node when you run out of space, and until then, you can use 100% of the SSDs flash capacity, instead of up-front wasting capacity just to never have to decrease the drive's usable capacity over the warranty period.
Give me, say, a Samsung 990 Pro 2 TB for 250 EUR but with firmware for ZNS-reformatting, instead of the 200 EUR MSRP/173 EUR Amazon.de price for the normal version.
Oh, and please let me use a decent portion of that 2 GB LPDDR4 as controller memory buffer at least if I'm in a ZNS-only formatting situation. It's after all not needed for keeping large block translation tables around, as ZNS only needs to track where physically a logical zone is currently located (wear leveling), and which individual blocks are marked dead in that physical zone (easy linear mapping between the non-contiguous usable physical blocks and the contiguous usable logical blocks). Beyond that, I guess technically it needs to keep track of open/closed zones and write pointers and filled/valid lengths.
Furthermore, I don't even need them to warranty the device lifespan in ZNS, only that it isn't bricked from activating ZNS mode. It would be nice to get as many drive-writes warranty as the non-ZNS version gets, though.
ZNS (Zoned Namespace) technology seems to offer significant benefits by reducing write amplification and improving hardware efficiency. It makes sense that manufacturers would push for ZNS adoption, as it can enhance performance without needing complex firmware. The potential for using lower-quality flash effectively is also intriguing. However, the market dynamics, like the value added by OEM stickers and the need for write-back capacitors, complicate things. Overall, ZNS appears to be a promising advancement for specific applications.
The kernel could implement a non-flushing barrier, even if the underlying device doesn't. You could even do it without any barrier support at all from the underlying device, as long as it reliably tells you when each request has completed; you just don't send it any requests from after the barrier until all the requests before the barrier have completed.
That would not work as you describe it. The device will return completion upon the writes reaching its cache. You need a flush to ensure that the data reaches stable storage.
You could probably abuse Force Unit Access to make it work by marking all IOs as Force Unit Access, but a number of buggy devices do not implement FUA properly, which defeats the purpose of using it. That would be why Microsoft disabled the NTFS feature that uses FUA on commodity hardware:
What you seem to want is FreeBSD’s UFS2 Softupdates that uses force unit access to avoid the need for flushes for metadata updates. It has the downside that it is unreliable on hardware that does not implement FUA properly. Also, UFS2 softupdates does not actually implement do anything to protect data when fsync(2) is called if this mailing list email is accurate:
> Synchronous writes (or BIO_FLUSH) are needed to handle O_SYNC/fsync(2) properly, which UFS currently doesn't care about.
That said, avoiding flushes for a fsync(2) would require doing FUA on all IOs. Presumably, this is not done because it would make all requests take longer all the time, raising queue depths and causing things to have to wait for queue limits more often, killing performance. Raising the OS queue depth to compensate would not work since SATA has a maximum queue depth of 32, although it might work for NVMe where the maximum queue depth is 65536, if keeping track of an increased number of inflight IOs does not cause additional issues at the storage devices (such as IOs that never complete as long as the device is kept busy because the device will keep reordering them to the end of the queue).
Using FUA only on metadata as is done in UFS2 soft updates improves performance by eliminating the need for journalling in all cases but the case of space usage, which still needs journalling (or fsck after power loss if you choose to forgo it).
Just get modules or strip from Yuju; I have zero bad experience over many years with them.
Sure, it's not cheap, but IMO ~1$/W plus simple PSU (either some standard voltage, or dimmable current, depending on what you got) for good and 1.5~2$/W for very good CRI is quite fine.
Yep. I’ve been replacing all the bulbs in my house with Yuji SunWave, and the difference is astonishing. I just put in four of their PAR30 4000K bulbs above my kitchen island, and the first time I turned the lights on at night I gasped at how much it looked like sunlight. (Then again, my wife said she couldn’t tell much of a difference and suggested my reaction was possibly confirmation bias, so YMMV.)
They’re quite expensive compared to normal LED bulbs, but it’s hard to argue against the quality of life improvement, particularly in the winter where I work remotely from a home office all day.
I was actually considering setting up an high brightness array of their full spectrum lighting above my desk. I know the article mentions diffuse lighting is best, but for some odd reason I prefer “spotlight” style. I don’t know why—it just feels cozier to me.
One thing I’ve noticed as I’ve learned more about lighting is that the brighter the light, the better cool color temperatures start to look. For a long time I hated anything above 3000K (too “office-like”) but 4000K actually starts looking pretty good around ~7,000 lumens directly overhead, and I imagine 5000K would look alright above 15,000 lumens or so (perceived brightness is a logarithmic function of luminance). IMO 5000K looks downright ghastly in a home setting for the typical range of 500-800 lumens that most bulbs sell at nowadays.
Yeah, central Europe, probably also Eastern, just stay out of River banks or build with sufficient foundations, debris-catchers, and nothing vulnerable below the first above-ground floor. Yes, this includes making sure the interior walls down there are fine from soaking 24 hours. And no electricity for a week after that.
The reason being that you want to rely on your home after such a disaster, if you get hit.
Yes, Eastern Europe is very safe. For example, Ukraine had very few natural disasters and floods over the decades. Most disasters were man-made, such as famine, Chornobyl and war. If Nature doesn't get you, humans will...
I'm looking at setting up a trial system for 39c3 to allow hunting down tools given out from the logistics department (pallet jacks, ladders, if cheap enough pallets that get left unattended).
Timeline for that is 10-11 months from now for when hardware has to exist and work.
I'd think of 2 or 3 AA batteries stuck to a small UWB PCB and stuck with tape of suitable type to the tool.
Are 10$ each doable? I don't see why not, but can't find any board akin to a Bluepill or ESP32-VROOM or PiPico containing the HF part.
The idea would be with base stations that can see each other well enough to synchronize and perform role-reversed pseudoranging to the tracker.
While definitely not as cool, this might be achievable with the same indoor positioning method the c3nav app uses, which would probably be accurate enough to track larger items at least to a few meters. After that, you can hopefully spot them easily, or maybe even use Bluetooth hot-or-cold to track them down further.
An ESP32 with a battery controller (wemos clone) + a little pillow cell would be around 6€ each (less if you buy in bulk).
1) It's actually not that good, sadly.
2) It's not up that early, as it depends on much of the networking to be set up before the WiFi works. The UWB system would be set up in around 1-2 hours just walking around with a load of wall wart/radio unit pairs and plugging them into sufficiently convenient outlets around the facility. They self-organize by ranging each other, and then you just take a device with UWB and RTK-GPS that's hooked up to the free (login-walled, but free) synthetic reference station service from the state's surveying bureau, and range in the fine locations of the base stations from a few points by pretty much just walking around the building's perimeter/fresh-air-access-doors to catch both GPS and UWB base stations.
If the base stations are fixed units that mechanically hold to the outlet, noting down with a reference image for easier finding where exactly they're plugged in lets one skip the GPS walk step for next year.
Use one that has the "240VDC (China only)" rating, and feed them proper DC.
Or get the modern western ~300V DC input ones, there's no good (technical) reason to feed AC from a non-grid-tie inverter to a SMPS-only circuit.
The DC can be quite passive, just switched in via a relay and anti-reverse-current-diode together with bridge-rectified mains, she otherwise just bare battery bank voltage
There's a reason modern data centers use that style of setup (except with a central power factor correcting rectifier, not a plain bridge rectifier, and often hanging the batteries on it directly using controlled rectifier output voltage to control battery charging).
Sorry for the late (and now in wrong thread) reply; is https://news.ycombinator.com/item?id=42318876 still active?
If so, happy to have a chat on it. If you want, let me know how to contact you best (feel free to send me mail to d10.pw).
actually, that was the point of my comment a few parent generations up from linked: by hanging the train under the rail, you get perfect banking for basically free. Fair, entry and exit of turns has to be handled smoothly, but you get passive pendulum-based perfect bank angle at any speed from 0 to the maximum allowed for that radius.
And while it's certainly not cheap to be forced to build the track as "technically a bridge", the lack of serious span makes the cost not actually that bad relative to train track in locations where the curve radius and speeds tend to actually be used (valleys narrow enough to need quite tight radii, as well as near existing infrastructure: if you're already bridging, it's easy to design the pillar point foundations to not conflict with existing usage).
Oh, and about the coffee you mentioned: just like bus and subway, (open) drinks and food are not allowed anyways. In any case, the only substantial forces would be increased gravity, and whatever traction limited acceleration along the direction of travel (this would be with deliberate jerk minimization, though, as people would otherwise loose their footing, where the currently active limits for subways come from).
The reason it hadn't yet been supported btw. is that they explicitly wanted to allow fully parallel processing of commands in a queue, at least for submissions that concurrently exist in the command queue. In practice I don't see why this would have to be enforced to such an extend, as the only reason for out-of-order processing I can think of is that the auxiliary data of a command is physically located in host memory and the DMA reads across PCIe from the NVMe controller to the host memory happen to complete out-of-order for host DRAM controller/pattern reasons. Thus it might be something you'd not want to turn on without using controller memory buffer (where you can mmap some of the DRAM on the NVMe device into host memory, write your full-detail commands directly to this across the PCIe, and keep the NVMe controller from having to first send a read request across PCIe in response to you ringing it's doorbell: instead it can directly read from it's local DRAM when you ring the doorbell).