FIDO2, LetsEncrypt, pre-allocation, Btrfs

1. Google's FIDO2/Passkeys Issues: A User Experience - When Google recently had issues with their FIDO2/Passkeys implementation, they managed to break all security keys, which was quite an unpleasant surprise. While others have had similar problems - as someone mentioned, Microsoft has struggled with these issues multiple times - at least Microsoft hasn't permanently broken things or changed practices, despite occasional issues. What makes this particularly frustrating is that I have three security keys registered [The keys are from two different manufacturers, Two keys were registered using Linux/Firefox combination, One key was registered using Windows/Edge combination], and all of them are experiencing the exact same issue. This clearly shows it's not a problem with the keys themselves, though some might jump to that conclusion. While these keys would work if re-registered after Google's changes, that's impossible since the existing registrations are broken. Even if I remove the key and re-register it, it's STILL broken. - This makes it highly unlikely that I somehow managed to break all the keys myself or that the issues are directly related to the operating system or browser. Furthermore, the Linux-registered keys have their firmware updates installed, while the Windows-registered key doesn't even support firmware updates, so that can't be the source of the problem either. - Just one example how FIDO2/Passkeys can seriously let you down. And this is also a classic ... case ... nobody cares...

2. Let's Encrypt - We Issued Our First Six Day Cert (@ letsencrypt.org) - Short term certs are finally here, for those whom need it.

3. When optimizing one large file handling process I started to think that why nobody's using pre-allocation, because I know it's supported. Then I checked ways of doing it and fount three different methods. I didn't even remember these, but in the cases I'll need to handle large files efficiently, it's great that Python supports these features:
   os.posix_fallocate(fd, offset, len)
   os.posix_fadvise(fd, offset, len, advice)

4.  Here are the test results:
   
   Filesystem type is: 9123683e
   
   File size of posix_fallocate is 1048576 (256 blocks of 4096 bytes)
   ext:     logical_offset:        physical_offset: length:   expected: flags:
     0:        0..     255:   11571099..  11571354:    256:             last,unwritten,eof
   posix_fallocate: 1 extent found
   
   File size of end_seek_write_one_null is 1048576 (256 blocks of 4096 bytes)
   ext:     logical_offset:        physical_offset: length:   expected: flags:
     0:      255..     255:       3402..      3402:      1:        255: last,eof
   seek: 1 extent found
   
   File size of truncate_file_to_size is 1048576 (256 blocks of 4096 bytes)
   truncate: 0 extents found

5. As you can see, fallocate actually did the pre-allocation, even if file is unwritten. Truncate created sparse files. How if these files are filled in random order I guess the fallcoate one works better than the truncated one, but I don't know it. Let's try. Awesome, expectations got perfectly confirmed (!).

6. posix_fallocate: 1 extent found
   truncate: 256 extents found

7. This is the result after writing 256 x 4 KiB blocks into the file and calling fsync after each block. If fsync isn't called, this small test file doesn't actually make any difference, because it's buffered by kernel before being allocated and flushed to disk. Wonderful, I like these results.

8. Also my btrfs-maintenance script confirmed to work, it runs every 100 days and does basic maintenance for the file systems, balance, scrub and defrag (for rotational media 8M extent traget and for SSDs only 128k). It took 3 minutes to run, and it was 100 days since previous run. So that's not bad at all. And yeah, the HDD is excluded from the scrub part, because it would take a looong time. I'll schedule it manually when I know the system is going to be on long enough to the scrub to finish. Even the scrub actually does beautifully support resuming. Which is great!

2025-09-28