<LnL>
niksnut: question, what does the ordering of computeFSClosure mean?
<LnL>
I assume it has some semantics given that it can be reversed
<niksnut>
ordering?
__Sander__ has joined #nixos-dev
jtojnar has joined #nixos-dev
<LnL>
the iterator, is it random or do the leaves come first/last?
<niksnut>
there is no ordering right? since it returns a set rather than a list
<niksnut>
it would be better if it did return a topologically sorted list, since then the caller could avoid a call to topoSortPaths
<LnL>
aha, that's what I was looking for then :)
Synthetica has quit [Quit: Connection closed for inactivity]
Lisanna has quit [Ping timeout: 240 seconds]
Lisanna has joined #nixos-dev
<gchristensen>
so I'm suspecting that the extreme slowness on the packet-t2a-1 machine was due to not having run fstrim in ages... but we'll see. I ran fstrim -- it took 9 hours -- I also wonder if perhaps there is something about a full dentry cache, getdents64() was taking many seconds to complete
<gchristensen>
or not..! the moment I sicked hydra back on it, the crazy slowness came back.
<gchristensen>
Packet's people suggest just replacing it, guessing it is a drive problem
<srhb>
gchristensen: I was under the impression that fstrim is usually a bad idea on modern drives (provided they're properly overprovisioned) ?
orivej has joined #nixos-dev
<gchristensen>
no idea?
<gchristensen>
certainly isn't as necessary on properly overprovisioned disks -- which this datacenter-class disk definitely is -- but also the SMART data suggests it has degraded by 110/255
<srhb>
gchristensen: A comparison with a similar fresh drive would be nice at the very least. :-P
<gchristensen>
on the SMART data? the other packet node is a samsung EVO and so not comparable
<ekleog>
how would fstrim be a bad idea? it's just telling the firmware a block is free, isn't it?
<ekleog>
it's maybe useless, but I don't really get how it can be actively negative
<gchristensen>
my understanding is: it is not good if you run it constantly, but a periodic / scheduled thing is okay
<srhb>
ekleog: Right, I didn't mean to imply it's worse than useless (except for the pressure you put on the disk)
<LnL>
gchristensen: have you talked to packet, maybe it's some kind of issue with the machine itself
orivej has quit [Ping timeout: 268 seconds]
globin has joined #nixos-dev
<gchristensen>
LnL: yeah just this morning, they said: I would think that at this stage I’d replace with a different machine….let our ops folks help with hardware fixing. an overnight `fstrim` is a bad sign. I don’t think very many people really know how SSDs work (except that they are supposed to be very fast, and that they evidently have a finite lifespan)
<srhb>
fwiw it's also worth overprovisioning them manually if they're very write-heavy.
<srhb>
Well, sometimes :)
<gchristensen>
my understanding is this disk is wildly overprovisioned
<ekleog>
hmm, I guess the metadata sectors used by the firmware can get burned out if they aren't properly moved across the sectors upon rewrites… or maybe NAND flash works differently from the NOR flash I'm used to (with NOR I see a quite nice way to not use the same sector too much for the firmware's metadata, I think)
Synthetica has joined #nixos-dev
pie___ has joined #nixos-dev
pie__ has quit [Remote host closed the connection]
worldofpeace has quit [Read error: Connection reset by peer]
worldofpeace_ has joined #nixos-dev
alp has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
drakonis has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
asymmetric_ has joined #nixos-dev
drakonis has quit [Ping timeout: 252 seconds]
asymmetric has quit [Ping timeout: 245 seconds]
asymmetric_ has quit [Ping timeout: 250 seconds]
<__Sander__>
Ericson2314: hi I was curious. have you managed to find some time to take a look at https://github.com/NixOS/nixpkgs/pull/50596 ? (the android cross compiling part)