Another data corruption, fortunately not fatal, with btrfs.
Uncategorized
19
Posts
10
Posters
99
Views
-
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
-
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
Don't forget to connect the employee to the UPS, too.
-
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
@stefano I honestly can't believe how these sorts of issues can keep cropping up with btrfs even today. A hard system shutdown or reboot is an undesirable but certainly by no means uncommon event. And btrfs certainly has all the elements that would *enable* it to handle them gracefully in as close to a guaranteed fashion as one can reasonably get. To say nothing of *one* disk in a redundant array having bad data requiring physical intervention to get to a working state... yikes!
-
Don't forget to connect the employee to the UPS, too.
This post is deleted! -
This post is deleted!
The UPS was trying to commit suicide
-
@stefano I honestly can't believe how these sorts of issues can keep cropping up with btrfs even today. A hard system shutdown or reboot is an undesirable but certainly by no means uncommon event. And btrfs certainly has all the elements that would *enable* it to handle them gracefully in as close to a guaranteed fashion as one can reasonably get. To say nothing of *one* disk in a redundant array having bad data requiring physical intervention to get to a working state... yikes!
This post is deleted! -
The UPS was trying to commit suicide
This post is deleted! -
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
-
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
@stefano These incidents always point to a poorly designed electrical installation where servers are not isolated from other electrical devices to prevent interference, particularly issues caused by harmonics 🤷🏻
-
@stefano These incidents always point to a poorly designed electrical installation where servers are not isolated from other electrical devices to prevent interference, particularly issues caused by harmonics 🤷🏻
This post is deleted! -
undefined oblomov@sociale.network shared this topic on
-
This post is deleted!
This post is deleted! -
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
@stefano what would explain that a low activity fs would get wrecked this way… sounds weird; unless btrfs keeps things in memory and never go sync.
-
@stefano what would explain that a low activity fs would get wrecked this way… sounds weird; unless btrfs keeps things in memory and never go sync.
This post is deleted! -
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
This post is deleted! -
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
Btrfs - the name says it all. "BetterFS" but misspelled by serverside Javascript hipsters. It needs to effin burn.
I'd take FAT32 over that monstrosity any day.
It is way, way worse than the tiramisu pizza abomination.
Sorry not sorry.
-
Another data corruption, fortunately not fatal, with btrfs. Two mirrored disks that have little activity. On the same server, Proxmox 9, there is also a ZFS pool (mirrored, more active). Same type of disks.
An employee mistakenly connected an electric heater to a socket protected by the UPS, and the server rebooted brutally.
Upon reboot, one of the two btrfs disks reported:
[ 167.015266] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.017007] BTRFS error (device sdd): parent transid verify failed on 873906176 wanted 998679 found 998677
[ 167.052517] BTRFS error (device sdd): open_ctree failed mount: /btrfs: can't read superblock on /dev/sdd.Result: unable to mount, even in degraded mode. The only way was to disconnect sdd and mount the other disk in degraded mode.
No issues with the ZFS pool.
Needless to say, I'm now copying the data to ZFS, and before tomorrow, these two disks will be a new ZFS pool.
@stefano I have never used btrfs. But I always read horror stories about it.
All I understand about btrfs is it's eternally in beta testing phase.
-
Btrfs - the name says it all. "BetterFS" but misspelled by serverside Javascript hipsters. It needs to effin burn.
I'd take FAT32 over that monstrosity any day.
It is way, way worse than the tiramisu pizza abomination.
Sorry not sorry.
@h3artbl33d @stefano Butter Fuss. I hope it becomes reliable someday, but I won't use it until it's been stable for some years. Same reason I won't use native ZFS encryption. People swear by both, and they keep losing data.
-
@h3artbl33d @stefano Butter Fuss. I hope it becomes reliable someday, but I won't use it until it's been stable for some years. Same reason I won't use native ZFS encryption. People swear by both, and they keep losing data.
This post is deleted! -
Btrfs - the name says it all. "BetterFS" but misspelled by serverside Javascript hipsters. It needs to effin burn.
I'd take FAT32 over that monstrosity any day.
It is way, way worse than the tiramisu pizza abomination.
Sorry not sorry.
This post is deleted!
Gli ultimi otto messaggi ricevuti dalla Federazione
-
just went to start the hem of a top-down sweater i'm knitting
pattern says "switch to US 4 needle"
"what do you mean, switch to"
knit practically the whole damn thing on needles two sizes too small 💀
-
-
@wild1145@mastodonapp.uk that's completely fair. I can certainly understand the risk in suggesting an instance whose uptime and longevity you cannot guarantee.
FWIW I am a developer working on ActivityPub integration in NodeBB, a forum software. I am active in AP development circles and am committed to ensuring the properties I host stick around. The differentiator with us is that you can get more of that medicine-focused feel due to our focus on local categories/feeds, while maintaining the global fediverse connection. 🙂
-
@andre123 penso di aver trovato il tuo "kit" su amazon. Hai dovuto saldare i pin (sono sicuro non sia il nome giusto...) tra scheda e schermo? @snow
-
@julian 100%, we've provided some links in our e-mail to resources for migrating in general, there's nothing we can do obviously to push accounts out to other instances and all we've done is stood up fedimedi.com because we wanted to be able to let folks move their posts (And Mastodon doesn't currently have a way to make that work). I've pointed folks to our other instances because obviously I know they're sticking around for a while where we're maintaining them.
-
Hi @wild1145@mastodonapp.uk, can we discuss having postcall.pub in the loop to serve as a landing zone for people leaving med-mastodon?
NodeBB Inc. (through me) is funding and maintaining this instance. It was built out specifically for the needs of that community when the site was first at risk of disconnection.
It result sucks that you are not able to get the domain sorted out. I empathize fully!
-
@wild1145@mastodonapp.uk @wild1145@universeodon.com Thanks Ryan
I’ve tagged him in a post on BlueSky in the hope he will connect with you.
I really don’t want to migrate.
Appreciate you keeping things going for March so I can put off the pain just a little longer :).
Paul Mackey
-
My robots will be able to target...I mean, see...people quite soon, now.
