Atemu

joined 5 years ago
MODERATOR OF
[–] Atemu@lemmy.ml 2 points 1 year ago

Monitor I/O on the drive; is anything using it while your system is idle?

What's I/O like when loading an album?

[–] Atemu@lemmy.ml 3 points 1 year ago (1 children)

Does it work if you enable VRR via xorg config?

Which xorg driver are/were you using, amdgpu or modesetting?

[–] Atemu@lemmy.ml 2 points 1 year ago

Then for a day and a half after I was working on that spreadsheet, it showed up at the top of the suggested videos.

Again, which applications had access to your clipboard and user files at that time? If any of the applications running on your computer was stealing your data and selling it for financial gain, Google would likely be buying it and obviously using it against you.

You also have to consider side-channels. Were you or your friends talking about that spreadsheet project via Discord or some other known abuser? Did you talk about it with a person in your room while daddy Google or Amazon were listening? (Alexa in the room, Google assistant on your phone etc.)

in short: years of nothing, nothing, nothing, TWO DAYS OF TRANS VIDEO SUGGESTIONS, and then since, nothing, nothing, nothing.

This might simply be expectation bias. You may have been shown such suggestions in the same pattern before and simply didn't notice because, contrary to the present, the topic wasn't on your mind and simply forgot about it because you're being shown irrelevant suggested topics all the time.

Even after reading a lot of people telling me that it is just The Algo^TM^ at work, that incident seems so razor specific to activity I was simply doing on my computer at the same time Youtube was open rather than anything that could be related to my personal interests.

That's how "The Algo^TM^" works. Google gathers data on you directly through its applications, from 3rd parties selling data they stole from you and indirectly through the same process from people you associate with.
It's even possible that some data broker simply made up the fact that you're trans. Google could have then assumed it's true because you associate with trans people here. I could very well see that happen in an enshittified system such as Google.

[–] Atemu@lemmy.ml 3 points 1 year ago

internet chromesplorer

I'm stealing that.

[–] Atemu@lemmy.ml 1 points 1 year ago

Edge is so privileged you can't remove it... well, you kinda just can't remove it..

That will have to change with the DMA becuase otherwise M$ will get ...a really big slap on the wrist or something.

[–] Atemu@lemmy.ml 4 points 1 year ago

This reads like a phrase from Half as Interesting.

[–] Atemu@lemmy.ml 6 points 1 year ago

And a ton of historical content.

[–] Atemu@lemmy.ml 1 points 1 year ago

It's too early to tell; you must investigate further.

[–] Atemu@lemmy.ml 3 points 1 year ago* (last edited 1 year ago)

The process for this is that you want to set your prefix to the /boot partition in the (hd1, gpt1) syntax (use ls) and then load the "normal" module. From then on, you should have regular GRUB again and should be able to boot your OS to properly fix GRUB.

[–] Atemu@lemmy.ml 5 points 1 year ago (2 children)

Typing anything in another window that is not my browser

Which windows exactly? The apps you're typing things into might be spying on you.

M$ and their 738 parters really value your privacy, so if you're typing things into Excel...

copypasting the words "trans" and "talking"

What applications were running on your computer while you did this? Any of them could be recording clipboard history; it requires no special privilege.

Heck, I wouldn't be surprised if Windows itself was recording this and sent it to daddy M$ to train LLMs and maybe sell it as a little multi-billion side hustle.

transgender videos about "How to change your voice" start popping up in my feed. Please know I have zero interest in transgender politics/culture/anything, it is not something I have ever searched for or engaged in online.

Maybe Google knows something you don't? JK.

A more plausible explanation is that Google knows that you're in the Fediverse (ever Googled it?) which has a far above average concentration of queer people.

What is also plausible is that someone living with you (i.e. your family) or a friend is trans and you're obviously associated with them.

Google doesn't recommend queer content because they think you're queer but because it's what their data-defined statistical algorithms (""AI"") predicts you are likely to be interested in and therefore watch ads for. If you know a queer person or are often in contact with them, you are simply quite a bit more likely to be interested in queer people than the average and therefore more likely to click on queer content.

Possible that Youtube is reading my clipboard? Reading my keystrokes?

Youtube itself? Near impossible.

Other applications? Possible but likelihood unknown.

Listening to an album via VLC, while Youtube is open in my browser. Suddenly, more tracks from that album start showing up in my suggested feed. Possible Youtube is reading the titles of other apps current open on my machine? (VLC changes its active title to the name of whatever file is currently open)

Again, Youtube itself directly isn't doing anything like this. If that album is related to what you were listening to on YT or is even simply also popular with people who listed to the same things on YT as you do or are just generally similar to your person; that's all it takes for YT to attempt to show it to you.

Also note again that any application on your Windows or Linux PC can read the window titles of any other application or even simply scan your media library or other files.

Discord does this for instance for their rich presence function for instance and I would again not be surprised if there was a little multi-billion side-hustle going on.

I use Youtube all the time as my personal version of Spotify.

If you're not reliant on YT's recommendations, I'd recommend you to download the songs you want to listen to and listen to them on a local player.

[–] Atemu@lemmy.ml 6 points 1 year ago

XZ is a slog to compress and decompress but compresses a bit smaller than zstd.

zstd is quite quick to compress, very quick to decompress, scales to many cores (vanilla xz is single-core only) and scales a lot further in the quicker end of the compression speed <-> file size trade-off spectrum while using the same format.

[–] Atemu@lemmy.ml 1 points 1 year ago

I don't like the Piped bot at all.

What should be posted on the internet should be the canonical source of some content, not a proxy for it. If users prefer a proxy, they should configure their clients to redirect to the proxy. Piped instances come and go and the entire project is at the mercy of Google tolerating it/not taking action against it, so it could be gone tomorrow.

I use piped myself. I have client-side configurations which simply redirects all Youtube links to my piped instance. No need for any bots here.

 

I assume many of you host a DMS such as Paperless and use it to organise the dead trees you still receive in the snail mail for some reason in the year of the lord 2023.

How do you encode your scans? JPEG is pretty meh for text even at better quantisation levels ("dirty" artefacts everywhere) and PNGs are quite large. More modern formats don't go into a PDF, which means multiple pages aren't possible (at least not in Paperless).

Discussion on GH: https://github.com/paperless-ngx/paperless-ngx/discussions/3756

 
This changeset adds extent-based data encryption to fscrypt.
Some filesystems need to encrypt data based on extents, rather than on
inodes, due to features incompatible with inode-based encryption. For
instance, btrfs can have multiple inodes referencing a single block of
data, and moves logical data blocks to different physical locations on
disk in the background. 

As per discussion last year in [1] and later in [2], we would like to
allow the use of fscrypt with btrfs, with authenticated encryption. This
is the first step of that work, adding extent-based encryption to
fscrypt; authenticated encryption is the next step. Extent-based
encryption should be usable by other filesystems which wish to support
snapshotting or background data rearrangement also, but btrfs is the
first user. 

This changeset requires extent encryption to use inlinecrypt, as
discussed previously. There are two questionable parts: the
forget_extent_info hook is not yet in use by btrfs, as I haven't yet
written a test exercising a race where it would be relevant; and saving
the session key credentials just to enable v1 session-based policies is
perhaps less good than 

This applies atop [3], which itself is based on kdave/misc-next. It
passes most encryption fstests with suitable changes to btrfs-progs, but
not generic/580 or generic/595 due to different timing involved in
extent encryption. Tests and btrfs progs updates to follow.


[1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
[2] https://lore.kernel.org/linux-fscrypt/80496cfe-161d-fb0d-8230-93818b966b1b@dorminy.me/T/#t
[3]
https://lore.kernel.org/linux-fscrypt/cover.1687988119.git.sweettea-kernel@dorminy.me/

2
submitted 2 years ago* (last edited 2 years ago) by Atemu@lemmy.ml to c/btrfs@lemmy.ml
 
btrfs quota groups (qgroups) are a compelling feature of btrfs that
allow flexible control for limiting subvolume data and metadata usage.
However, due to btrfs's high level decision to tradeoff snapshot
performance against ref-counting performance, qgroups suffer from
non-trivial performance issues that make them unattractive in certain
workloads. Particularly, frequent backref walking during writes and
during commits can make operations increasingly expensive as the number
of snapshots scales up. For that reason, we have never been able to
commit to using qgroups in production at Meta, despite significant
interest from people running container workloads, where we would benefit
from protecting the rest of the host from a buggy application in a
container running away with disk usage.  This patch series introduces a simplified version of qgroups called
simple quotas (squotas) which never computes global reference counts
for extents, and thus has similar performance characteristics to normal,
quotas disabled, btrfs. The "trick" is that in simple quotas mode, we
account all extents permanently to the subvolume in which they were
originally created. That allows us to make all accounting 1:1 with
extent item lifetime, removing the need to walk backrefs. However, this sacrifices the ability to compute shared vs. exclusive usage. It also
results in counter-intuitive, though still predictable and simple,
accounting in the cases where an original extent is removed while a
shared copy still exists. Qgroups is able to detect that case and count
the remaining copy as an exclusive owner, while squotas is not. As a
result, squotas works best when the original extent is immutable and
outlives any clones.

==Format Change==
In order to track the original creating subvolume of a data extent in
the face of reflinks, it is necessary to add additional accounting to
the extent item. To save space, this is done with a new inline ref item.
However, the downside of this approach is that it makes enabling squota
an incompat change, denoted by the new incompat bit SIMPLE_QUOTA. When
this bit is set and quotas are enabled, new extent items get the extra
accounting, and freed extent items check for the accounting to find
their creating subvolume. In addition, 1:1 with this incompat bit,
the quota status item now tracks a "quota enablement generation" needed
for properly handling deleting extents with predate enablement.

==API==
Squotas reuses the api of qgroups. The only difference is that when you
enable quotas via `btrfs quota enable`, you pass the `--simple` flag.
Squotas will always report exclusive == shared for each qgroup. Squotas
deal with extent_item/metadata_item sizes and thus do not do anything
special with compression. Squotas also introduce auto inheritance for
nested subvols. The API is documented more fully in the documentation
patches in btrfs-progs.

==Testing methodology==
Using updated btrfs-progs and fstests (relevant matching patch sets to
be sent ASAP)
btrfs-progs: https://github.com/boryas/btrfs-progs/tree/squota-progs
fstests: https://github.com/boryas/fstests/tree/squota-test

I ran '-g auto' on fstests on the following configurations:
1a) baseline kernel/progs/fstests.
1b) squota kernel baseline progs/fstests.
2a) baseline kernel/progs/fstests. fstests configured to mkfs with quota
2b) squota kernel/progs/fstests. fstests configured to mkfs with squota

I compared 1a against 1b and 2a against 2b and detected no regressions.
2a/2b both exhibit regressions against 1a/1b which are largely issues
with quota reservations in various complicated cases. I intend to run
those down in the future, but they are not simple quota specific, as
they are already broken with plain qgroups.

==Performance Testing==
I measured the performance of the change using fsperf. I ran with 3
configurations using the squota kernel:
- plain mkfs
- qgroup mkfs
- squota mkfs
And added a new performance test which creates 1000 files in a subvol,
creates 100 snapshots of that subvol, then unshares extents in files in
the snapshots. I measured write performance with fio and btrfs commit
critical section performance side effects with bpftrace on
'wait_current_trans'.

The results for the test which measures unshare perf (unshare.py) with
qgroup and squota compared to the baseline:

group test results
unshare results
          metric              baseline       current        stdev            diff
========================================================================================
avg_commit_ms                     162.13        285.75          3.14     76.24%
bg_count                              16            16             0      0.00%
commits                           378.20           379          1.92      0.21%
elapsed                           201.40        270.40          1.34     34.26%
end_state_mount_ns           26036211.60   26004593.60    2281065.40     -0.12%
end_state_umount_ns             2.45e+09      2.55e+09   20740154.41      3.93%
max_commit_ms                     425.80           594         53.34     39.50%
sys_cpu                             0.10          0.06          0.06    -42.15%
wait_current_trans_calls         2945.60       3405.20         47.08     15.60%
wait_current_trans_ns_max       1.56e+08      3.43e+08   32659393.25    120.07%
wait_current_trans_ns_mean    1974875.35   28588482.55    1557588.84   1347.61%
wait_current_trans_ns_min            232           232         25.88      0.00%
wait_current_trans_ns_p50            718           740         22.80      3.06%
wait_current_trans_ns_p95     7711770.20      2.21e+08   17241032.09   2761.19%
wait_current_trans_ns_p99    67744932.29      2.68e+08   41275815.87    295.16%
write_bw_bytes                 653008.80     486344.40       4209.91    -25.52%
write_clat_ns_mean            6251404.78    8406837.89      39779.15     34.48%
write_clat_ns_p50             1656422.40    1643315.20      27415.68     -0.79%
write_clat_ns_p99               1.90e+08      3.20e+08       2097152     68.62%
write_io_kbytes                   128000        128000             0      0.00%
write_iops                        159.43        118.74          1.03    -25.52%
write_lat_ns_max                7.06e+08      9.80e+08   47324816.61     38.88%
write_lat_ns_mean             6251503.06    8406936.06      39780.83     34.48%
write_lat_ns_min                    3354          4648        616.06     38.58%

squota test results
unshare results
          metric              baseline       current        stdev            diff
========================================================================================
avg_commit_ms                     162.13        164.16          3.14      1.25%
bg_count                              16             0             0   -100.00%
commits                           378.20        380.80          1.92      0.69%
elapsed                           201.40        208.20          1.34      3.38%
end_state_mount_ns           26036211.60   25840729.60    2281065.40     -0.75%
end_state_umount_ns             2.45e+09      3.01e+09   20740154.41     22.80%
max_commit_ms                     425.80        415.80         53.34     -2.35%
sys_cpu                             0.10          0.08          0.06    -23.36%
wait_current_trans_calls         2945.60       2981.60         47.08      1.22%
wait_current_trans_ns_max       1.56e+08      1.12e+08   32659393.25    -27.86%
wait_current_trans_ns_mean    1974875.35    1064734.76    1557588.84    -46.09%
wait_current_trans_ns_min            232           238         25.88      2.59%
wait_current_trans_ns_p50            718           746         22.80      3.90%
wait_current_trans_ns_p95     7711770.20       1567.60   17241032.09    -99.98%
wait_current_trans_ns_p99    67744932.29   49880514.27   41275815.87    -26.37%
write_bw_bytes                 653008.80        631256       4209.91     -3.33%
write_clat_ns_mean            6251404.78    6476816.06      39779.15      3.61%
write_clat_ns_p50             1656422.40       1581056      27415.68     -4.55%
write_clat_ns_p99               1.90e+08      1.94e+08       2097152      2.21%
write_io_kbytes                   128000        128000             0      0.00%
write_iops                        159.43        154.12          1.03     -3.33%
write_lat_ns_max                7.06e+08      7.65e+08   47324816.61      8.38%
write_lat_ns_mean             6251503.06    6476912.76      39780.83      3.61%
write_lat_ns_min                    3354          4062        616.06     21.11%

And the same, but only showing results where the deviation was outside
of a 95% confidence interval for the mean (default significance
highlighting in fsperf):
qgroup test results
unshare results
          metric              baseline       current        stdev            diff
========================================================================================
avg_commit_ms                     162.13        285.75          3.14     76.24%
elapsed                           201.40        270.40          1.34     34.26%
end_state_umount_ns             2.45e+09      2.55e+09   20740154.41      3.93%
max_commit_ms                     425.80           594         53.34     39.50%
wait_current_trans_calls         2945.60       3405.20         47.08     15.60%
wait_current_trans_ns_max       1.56e+08      3.43e+08   32659393.25    120.07%
wait_current_trans_ns_mean    1974875.35   28588482.55    1557588.84   1347.61%
wait_current_trans_ns_p95     7711770.20      2.21e+08   17241032.09   2761.19%
wait_current_trans_ns_p99    67744932.29      2.68e+08   41275815.87    295.16%
write_bw_bytes                 653008.80     486344.40       4209.91    -25.52%
write_clat_ns_mean            6251404.78    8406837.89      39779.15     34.48%
write_clat_ns_p99               1.90e+08      3.20e+08       2097152     68.62%
write_iops                        159.43        118.74          1.03    -25.52%
write_lat_ns_max                7.06e+08      9.80e+08   47324816.61     38.88%
write_lat_ns_mean             6251503.06    8406936.06      39780.83     34.48%
write_lat_ns_min                    3354          4648        616.06     38.58%

squota test results
unshare results
          metric              baseline       current        stdev            diff
========================================================================================
elapsed                           201.40        208.20          1.34      3.38%
end_state_umount_ns             2.45e+09      3.01e+09   20740154.41     22.80%
write_bw_bytes                 653008.80        631256       4209.91     -3.33%
write_clat_ns_mean            6251404.78    6476816.06      39779.15      3.61%
write_clat_ns_p50             1656422.40       1581056      27415.68     -4.55%
write_clat_ns_p99               1.90e+08      1.94e+08       2097152      2.21%
write_iops                        159.43        154.12          1.03     -3.33%
write_lat_ns_mean             6251503.06    6476912.76      39780.83      3.61%

Particularly noteworthy are the massive regressions to
wait_current_trans in qgroup mode as well as the solid regressions to
bandwidth, iops and write latency. The regressions/improvements in
squotas are modest in comparison in line with the expectation. I am
still investigating the squota umount regression, particularly whether
it is in the umount's final commit and represents a real performance
problem with squotas.

Link: https://github.com/boryas/btrfs-progs/tree/squota-progs
Link: https://github.com/boryas/fstests/tree/squota-test
Link: https://github.com/boryas/fsperf/tree/unshare-victim
 

So, heute ist mir wieder eine mörderische Fliege ins Auge geflogen und ich hab keinen Bock mehr drauf.

Was gibt's für Fahrradbrillen, die empfehlenswert sind?

Ich brauch das zum Pendeln, nicht für den Sport. Am liebsten wär mir daher eine, die semi-fest am Helm befestigt ist. Den Helm hab ich zusammen mit Tasche und Fahrrad immer überall dabei; ich will da halt nicht noch einen vierten Gegenstand, um den ich mich kümmern muss.

Da mir wenn's kalt ist immer die Nase wegen läuft und ich Tränen vom Fahrtwind unter Verdacht habe, würd ich die nach Möglichkeit auch im Winter verwenden wollen ohne dass sie beschlägt.

Ich trage sonst keine Brille; Dioptrien sind hier nicht benötigt/erwünscht. Getönt brauch ich nicht, aber so getönte Einsätze wären ggf. ne tolle Sache.

Was habt ihr für Erfahrungen und/oder Empfehlungen?

 

cross-posted from: https://lemmy.ml/post/1553943

Hi,

there are mainly core changes, refactoring and optimizations. Performance is improved in some areas, overall there may be a cumulative improvement due to refactoring that removed lookups in the IO path or simplified IO submission tracking.

No merge conflicts. Please pull, thanks.

Core:

  • submit IO synchronously for fast checksums (crc32c and xxhash), remove high priority worker kthread

  • read extent buffer in one go, simplify IO tracking, bio submission and locking

  • remove additional tracking of redirtied extent buffers, originally added for zoned mode but actually not needed

  • track ordered extent pointer in bio to avoid rbtree lookups during IO

  • scrub, use recovered data stripes as cache to avoid unnecessary read

  • in zoned mode, optimize logical to physical mappings of extents

  • remove PageError handling, not set by VFS nor writeback

  • cleanups, refactoring, better structure packing

  • lots of error handling improvements

  • more assertions, lockdep annotations

  • print assertion failure with the exact line where it happens

  • tracepoint updates

  • more debugging prints

Performance:

  • speedup in fsync(), better tracking of inode logged status can avoid transaction commit

  • IO path structures track logical offsets in data structures and does not need to look it up

User visible changes:

  • don't commit transaction for every created subvolume, this can reduce time when many subvolumes are created in a batch

  • print affected files when relocation fails

  • trigger orphan file cleanup during START_SYNC ioctl

Notable fixes:

  • fix crash when disabling quota and relocation

  • fix crashes when removing roots from drity list

  • fix transacion abort during relocation when converting from newer profiles not covered by fallback

  • in zoned mode, stop reclaiming block groups if filesystem becomes read-only

  • fix rare race condition in tree mod log rewind that can miss some btree node slots

  • with enabled fsverity, drop up-to-date page bit in case the verification fails

 

Hi,

there are mainly core changes, refactoring and optimizations. Performance is improved in some areas, overall there may be a cumulative improvement due to refactoring that removed lookups in the IO path or simplified IO submission tracking.

No merge conflicts. Please pull, thanks.

Core:

  • submit IO synchronously for fast checksums (crc32c and xxhash), remove high priority worker kthread

  • read extent buffer in one go, simplify IO tracking, bio submission and locking

  • remove additional tracking of redirtied extent buffers, originally added for zoned mode but actually not needed

  • track ordered extent pointer in bio to avoid rbtree lookups during IO

  • scrub, use recovered data stripes as cache to avoid unnecessary read

  • in zoned mode, optimize logical to physical mappings of extents

  • remove PageError handling, not set by VFS nor writeback

  • cleanups, refactoring, better structure packing

  • lots of error handling improvements

  • more assertions, lockdep annotations

  • print assertion failure with the exact line where it happens

  • tracepoint updates

  • more debugging prints

Performance:

  • speedup in fsync(), better tracking of inode logged status can avoid transaction commit

  • IO path structures track logical offsets in data structures and does not need to look it up

User visible changes:

  • don't commit transaction for every created subvolume, this can reduce time when many subvolumes are created in a batch

  • print affected files when relocation fails

  • trigger orphan file cleanup during START_SYNC ioctl

Notable fixes:

  • fix crash when disabling quota and relocation

  • fix crashes when removing roots from drity list

  • fix transacion abort during relocation when converting from newer profiles not covered by fallback

  • in zoned mode, stop reclaiming block groups if filesystem becomes read-only

  • fix rare race condition in tree mod log rewind that can miss some btree node slots

  • with enabled fsverity, drop up-to-date page bit in case the verification fails

34
TIL about /dev/full (en.wikipedia.org)
 

No, that's not a typo.

view more: ‹ prev next ›