LimeB

Members
  • Posts

    87
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

LimeB's Achievements

Rookie

Rookie (2/14)

4

Reputation

1

Community Answers

  1. Just to confirm. I can do this by just copying everything off, for mat, than copy it back over?
  2. After my last post, system booted up and went into a bad state probably within minutes but I didn't notice for a few hours. I went ahead and ran a memtest and no errors with 9 passes. I have moved the memory into dual channel, and I am still having issues. Now what I am seeing is within minutes of the array being started, my docker containers will crash, and can't start. I am seeing my cache drive being unmountable as per my other post. I can run the command you suggested, it gets me running again. Maybe I am running into multiple issues here because I'm not seeing the initial UI problem anymore but now more just docker keeps failing because of my cache drive. Attached is a diag after the latest boot and crash. This last time I did disable docker, started the array, then enabled docker. diagnostics-20240204-0119.zip
  3. Maybe the macvlan inadvertently got changed when I was then messing with some other settings for working on something else. I felt like it was staying stable after I initially changed to ipvlan but thinking back, it must have got changed back and I became unstable again. Now it is changed again and I'll see how it holds up, along with running a memtest.
  4. I think I am still having related issues, or maybe it is something else. I again had hard reset the box, and after that I had an issue which I created another post about with my cache drive which it is working again. Twice though docker containers were not running, stopped I guess at some point, and wouldn't start until I rebooted. Currently this was happening, I am trying to stop the array but it is not stopping. Attached is the current diag and I have tried physically rebooting it yet. Maybe this is a separate issue from before but i'm not certain. diagnostics-20240127-2005.zip
  5. Awesome. I am back in business! Thank you.
  6. I had an unclean shutdown and coming back up, my cache drive is not mountable. Attached are my diags. Unmountable disk present: Cache • Samsung_SSD_970_EVO_Plus_2TB_S59CNM0RA30351D (nvme0n1) btrfs check with -n [1/7] checking root items [2/7] checking extents [3/7] checking free space tree free space info recorded 5227 extents, counted 5237 wanted offset 50535092224, found 50535088128 cache appears valid but isn't 50487885824 free space info recorded 1388 extents, counted 1398 There are still entries left in the space cache cache appears valid but isn't 59077820416 [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups skipped (not enabled on this FS) Opening filesystem to check... Checking filesystem on /dev/mapper/nvme0n1p1 UUID: 511844b9-b3cc-4da0-bac2-e4c2d3fcff7f found 1031122690048 bytes used, error(s) found total csum bytes: 646066272 total tree bytes: 1119682560 total fs tree bytes: 158973952 total extent tree bytes: 107642880 btree space waste bytes: 243970093 file data blocks allocated: 5365445775360 referenced 955935105024 btrfs check with no modifier [1/7] checking root items [2/7] checking extents [3/7] checking free space tree free space info recorded 5227 extents, counted 5237 wanted offset 50535092224, found 50535088128 cache appears valid but isn't 50487885824 free space info recorded 1388 extents, counted 1398 There are still entries left in the space cache cache appears valid but isn't 59077820416 [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups skipped (not enabled on this FS) Opening filesystem to check... Checking filesystem on /dev/mapper/nvme0n1p1 UUID: 511844b9-b3cc-4da0-bac2-e4c2d3fcff7f found 1031122690048 bytes used, error(s) found total csum bytes: 646066272 total tree bytes: 1119682560 total fs tree bytes: 158973952 total extent tree bytes: 107642880 btree space waste bytes: 243970093 file data blocks allocated: 5365445775360 referenced 955935105024 btrfs check with -L [1/7] checking root items [2/7] checking extents [3/7] checking free space tree free space info recorded 5227 extents, counted 5237 wanted offset 50535092224, found 50535088128 cache appears valid but isn't 50487885824 free space info recorded 1388 extents, counted 1398 There are still entries left in the space cache cache appears valid but isn't 59077820416 [4/7] checking fs roots [5/7] checking only csums items (without verifying data) [6/7] checking root refs [7/7] checking quota groups skipped (not enabled on this FS) Opening filesystem to check... Checking filesystem on /dev/mapper/nvme0n1p1 UUID: 511844b9-b3cc-4da0-bac2-e4c2d3fcff7f found 1031122690048 bytes used, error(s) found total csum bytes: 646066272 total tree bytes: 1119682560 total fs tree bytes: 158973952 total extent tree bytes: 107642880 btree space waste bytes: 243970093 file data blocks allocated: 5365445775360 referenced 955935105024 While it is not critical if I have to format the drive but hate to do it. Any thoughts on what I can try to fix it? diagnostics-20240124-0800.zip
  7. Appreciate the suggestion. Yesterday the UI died on me a few times, once while stopping docker. I made the change and so far it has been holding since yesterday. It is possible that maybe docker wasn't failing on me except that one time which I posted this 2 days ago but I was assuming it also had been.
  8. A few times since upgrading my parity drive to a larger one, I am having issues with my server going into a bad state. I feel like this is similar to what I initially saw happening when I switched from Intel to AMD but the issues went away after I change some recommended settings but I think I recall I even changed the BIOS back to defaults. It has been fine for a few years now. It seems like if I have to hard reset the system, it will boot up, run file while parity check is happening, but then later in the day, or next, the UI becomes unresponsive. I am able to SSH in and reset the UI. And say right now, I see that my docker containers are all but 1 stopped and the stopped ones are throwing an error. VMs will throw an error if I try to start them. Attached is my diags. diagnostics-20240108-1437.zip
  9. I ended up stumbling on this video and went with using the -L flag. After doing so, all is well again it seems. I also just realized I ran into corruption a few years ago and read through that thread as well. That one I also went through the repair with -L.
  10. I also did -n and this came up: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... sb_fdblocks 1348690186, counted 1369121098 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 inode 6892288466 - bad extent starting block number 4503567551069610, offset 0 correcting nextents for inode 6892288466 bad data fork in inode 6892288466 would have cleared inode 6892288466 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 6 - agno = 3 - agno = 5 - agno = 7 - agno = 1 - agno = 8 - agno = 9 - agno = 10 - agno = 4 entry "2013-11-28 002.JPG" at block 0 offset 128 in directory inode 6892288464 references free inode 6892288466 would clear inode number in entry at offset 128... inode 6892288466 - bad extent starting block number 4503567551069610, offset 0 correcting nextents for inode 6892288466 bad data fork in inode 6892288466 would have cleared inode 6892288466 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... entry "2013-11-28 002.JPG" in directory inode 6892288464 points to free inode 6892288466, would junk entry bad hash table for directory inode 6892288464 (no data entry): would rebuild would rebuild directory inode 6892288464 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting.
  11. I did that through the GUI method and this came up immediately: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.
  12. A few days ago I noticed that my server was acting up which the GUI was kind of working but then when I was trying to navigate to a few areas it just all together stopped working. I ended up having to do a hard reset on the box and now it is back up the main data disk I care about comes up as "Unmountable: Unsupported or no file system". Attached is the diagnostics after booting up now.
  13. Giving myself a bump. How would I try the other suggestions above?
  14. Kind of put this to the side and forgot about it but now I want to try to get this figured out. I am not sure how to do either of these suggestions.
  15. Appreciate the quick reply. I tried using the updated virtio drivers you linked but Windows says it was unable to install. Since it is my E drive I have tried: E:\ E:\vioscsi\ E:\vioscsi\w11\ E:\vioscsi\w11\amd64 And selected to include subfolders.