In Navy boot camp the person reviewing my security clearance application (which was filled out weeks before) was very helpful in the way he asked the critical question. “It says here you tried marijuana once. Is that true?”
"Well, some guy I didn't know very well said it was marijuana - but how would I know? All it seemed to do was make my eyes water, and give me a headache..."
Back in 1997 or so I bought an ATI video card that also had a Weezer video on the CD. I remember being amazed that it could play the video at 1024x768 with just a little bit of tearing.
Exactly. I question why the parent says you have to re-encrypt the drive.
Microsoft has the KEK or passphrase that can be used to derive the KEK. The KEK protects the DEK which is used to encrypt the data. Rotating the KEK (or KEKs if multiple slots are used) will overwrite the encrypted DEK, rendering the old KEK useless.
Or does BitLocker work differently than typical data at rest encryption?
BitLocker recovery keys are essentially the key to an at-rest, local copy of the real key. (I.e., they need access to the encrypted drive to get the real encryption key)
When you use a recovery key at preboot, it decrypts that on-disk backup copy of the encryption key with your numerical recovery key, and uses the decrypted form as the actual disk encryption key. Thus, you can delete & regenerate a recovery key, or even create several different recovery keys.
And if you don’t use a lot of data, at least US Mobile has a by the gig plan. My family has three phones on it for a total $30 per month. Those months that we go over, it automatically charges $2 for each extra GB, with data pooled between the lines.
It is easy to switch between Verizon, AT&T, and T-Mobile as well. This was helpful for me as all three of the networks normally have one bar or less at my house. T-mobile WiFi calling works more reliably than Verizon.
Mirroring between s3 providers would seemingly give protection against your account being locked at one of them.
I expect this becomes most interesting with l2arc and cache (zil) devices to hold the working set and hide write latency. Maybe would require tuning or changes to allow 1m writes to use the cache device.
I’m guessing v4 C didn’t have structs yet (v6 C does, but struct members are actually in the global namespace and are basically just sugar for offset and a type cast; member access even worked on literals. That’s why structs from early unix APIs have prefixed member names, like st_mode.
There may have been a early C without structs (B had none,) but according to Ken Thompson, the addition of structs to C was an important change, and a reason why his third attempt rewrite UNIX from assembly to a portable language finally succeeded. Certainly by the time the recently recovered v4 tape was made, C had structs:
~/unix_v4$ cat usr/sys/proc.h
struct proc {
char p_stat;
char p_flag;
char p_pri;
char p_sig;
char p_null;
char p_time;
int p_ttyp;
int p_pid;
int p_ppid;
int p_addr;
int p_size;
int p_wchan;
int *p_textp;
} proc[NPROC];
/* stat codes */
#define SSLEEP 1
#define SWAIT 2
#define SRUN 3
#define SIDL 4
#define SZOMB 5
/* flag codes */
#define SLOAD 01
#define SSYS 02
#define SLOCK 04
#define SSWAP 010
It seems pointless to issue flush commands when writing to an NVMe drive with a direct IO implementation that functions properly. The NVMe spec says:
> 6.8 Flush command
> …
> If a volatile write cache is not present or not enabled, then Flush commands shall complete successfully and have no effect.
And:
> 5.21.1.6 Volatile Write Cache
> …
> Note: If the controller is able to guarantee that data present in a write cache is written to non-volatile media on loss of power, then that write cache is considered non-volatile and this feature does not apply to that write cache.
If you know your application will only ever run against enterprise SSDs with power loss protection, then sending flush commands to the drive itself would indeed be pointless no-ops. But it if it's a flush command that has effects somewhere between the application layer and the NVMe drive (eg. if you're not using direct IO) or if there's any possibility of the code being run on a consumer SSD (eg. a developer's laptop) then the flush commands are probably worth including; the performance hit on enterprise drives will be very small.
IOCTLs can tell you if write caching is enabled or not. Can they reliably tell you whether the write cache is volatile, though? Many drives with PLPs still report volatile write caches, or at least did when I was testing this a few years back.
Per the definition of volatile write cache in the standard I quoted, pretty much any drive TLC drive in the hyperscalar, datacenter, or enterprise product lineup will have great write performance. They have a DRAM cache that is battery-backed, and as such is not a volatile write cache.
A specific somewhat dated example: Samsung 980 Pro (consumer client), PM9A1 (OEM client), and PM9A3 (datacenter) are very similar drives that have the same PCI ID and are all available as M.2. PM9A3 drives have power loss protection and the others don’t. It has very consistent write latency (on the order of 20 - 50 μs when not exceptionally busy) and very consistent throughput (up to 1.5 GB/s) regardless of how full it is. The same cannot be said of the client drives without PLP but with tricks like TurboWrite (aka pseudo-SLC). When more than 30% of the NAND is erased, the client drives can take writes at 5 GB/s but that rate falls off a cliff and gets wobbly when the pseudo-SLC cache fills.
Thanks! Yes, as the sibling noted, if you limit this to PLP drives it makes sense, but that is also a special case. Outside of the latency hit (which is significant in some cases), FLUSH is also nearly free on those though.
The original idea of boot environments in Solaris came from Live Upgrade, which worked at least as far back as Solaris 8. Live upgrade was not part of Solaris, rather it was an addon that came from the services or enterprise support parts of Sun.
Solaris 11 made boot environments a mandatory part of the OS, which was an obvious choice with the transition from
UFS to ZFS for the root fs. This came into Solaris development a bit before Solaris 11, so it was present in OpenSolaris and lives on in many forms of illumos.
In Navy boot camp the person reviewing my security clearance application (which was filled out weeks before) was very helpful in the way he asked the critical question. “It says here you tried marijuana once. Is that true?”
reply