skoub
Members-
Posts
66 -
Joined
-
Last visited
Converted
-
Gender
Male
-
Location
Quebec, Canada
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
skoub's Achievements
Rookie (2/14)
2
Reputation
-
error: shfs_mk_share, 6450: No space left on device (28)
skoub replied to skoub's topic in General Support
I've put 50GB and it solve the problem but I don't understand why. All my shared are set to 0 and it worked but maybe I had more space at that time. What is the purpose of this setting? It's to be sure that there's always a space available to this folder? -
Hi everyone! I wanted to create a new share on my array but it doesn't work. The error doesn't show on the UI but if I check the log, I see "emhttpd: error: shfs_mk_share, 6450: No space left on device (28): ioctl: /NewFolder". I tried to restart the array, reboot the server but without any success. I have enough space on my array and also on my USB key so I don't know how to solve it. I have attached the diagnostic file. Thank you for your help! tower-diagnostics-20230830-1214.zip
-
Problem with an Unmountable: Unsupported partition layout disk
skoub replied to skoub's topic in General Support
Just wanted to say that everything is back to normal now. Thank you again for all the support! -
Problem with an Unmountable: Unsupported partition layout disk
skoub replied to skoub's topic in General Support
The disk is now in the rebuilding process. By curiosity, what kind on information you where searching in the my diagnostics file? Thank you all for your help! -
Problem with an Unmountable: Unsupported partition layout disk
skoub replied to skoub's topic in General Support
Here's the new diagnostics tower-diagnostics-20220804-2252.zip -
Problem with an Unmountable: Unsupported partition layout disk
skoub replied to skoub's topic in General Support
-
Problem with an Unmountable: Unsupported partition layout disk
skoub replied to skoub's topic in General Support
I've done the filesystem check without the -n switch but no luck, the disk is still in "invalid partition layout" state. Here's the result: Phase 1 - find and verify superblock... - block cache size set to 148496 entries Phase 2 - using internal log - zero log... zero_log: head block 2270027 tail block 2270027 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Thu Aug 4 17:42:27 2022 Phase Start End Duration Phase 1: 08/04 17:42:04 08/04 17:42:13 9 seconds Phase 2: 08/04 17:42:13 08/04 17:42:14 1 second Phase 3: 08/04 17:42:14 08/04 17:42:18 4 seconds Phase 4: 08/04 17:42:18 08/04 17:42:18 Phase 5: 08/04 17:42:18 08/04 17:42:26 8 seconds Phase 6: 08/04 17:42:26 08/04 17:42:27 1 second Phase 7: 08/04 17:42:27 08/04 17:42:27 Total run time: 23 seconds done So my last option is to rebuild my disk? Can someone confirm the steps please? stop the array unassign the disk start the array without the disk format the disk with the option that is shown "Format will create a file system in all Unmountable disks" stop the array reassign the disk start the array let the system rebuild my disk -
Problem with an Unmountable: Unsupported partition layout disk
skoub replied to skoub's topic in General Support
I don't mind losing the data on this disk if I can get it back by rebuilding the array but if I can fix it without doing that, it would be great. Here's the result for the Check Filesystem: Phase 1 - find and verify superblock... - block cache size set to 148496 entries Phase 2 - using internal log - zero log... zero_log: head block 2270027 tail block 2270027 - scan filesystem freespace and inode maps... - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Tue Aug 2 22:21:54 2022 Phase Start End Duration Phase 1: 08/02 22:21:48 08/02 22:21:48 Phase 2: 08/02 22:21:48 08/02 22:21:49 1 second Phase 3: 08/02 22:21:49 08/02 22:21:53 4 seconds Phase 4: 08/02 22:21:53 08/02 22:21:53 Phase 5: Skipped Phase 6: 08/02 22:21:53 08/02 22:21:54 1 second Phase 7: 08/02 22:21:54 08/02 22:21:54 Total run time: 6 seconds -
Hi everyone, I have checked my server today and discovered that one of my disk show the message "Unmountable: Unsupported partition layout". This is not a new disk. It is there for many years now and I don't know why I got this message today. I have the option to format the disk but I'm not sure it's the way to go. What steps should I do to fix this? I have attached my diagnotics file in case it can help. Thank you for your help! tower-diagnostics-20220802-2027.zip
-
My shares doesn't use the cache drive. But to push the test further, i tried to write directly to the cache drive. This test is with a new share with the option "Use cache disc" to "Only". I obtain a stable 111mb/sec. This test is with a new share with the option "Use cache disc" to "Yes". The transfert is not as smooth varying from 92mb to 111mb/sec
-
@Frank1940, i'm copying large files >2GB. The spikes that I get is during the transfert of the same file. And thank you for the tip about posting updates on a new post! It make sens!
-
done!
-
Hi everyone! When i write to my shares, i do not get a smooth write speed. It always fluctuate up and down from 18mb/sec to 38-39mb/sec. I'm alone on my network, using an USB3 Gigabit Ethernet adapter. Is it possible to test write speed on my shares without using my laptop so i can remove my Ethernet adapter from the equation? Here's my server: tower-diagnostics-20190805-0200.zip
-
My system log report metadata I/O error in "xfs_trans_read_buf_map"
skoub replied to skoub's topic in General Support
Thank you. I have proceeded to the repair and it went well. I will check this week if it come back. About the system share and was on disk1, in fact, it was only the empty folder that i forgot the delete. I have moved everything to the cache drive. -
Hi everyone, In my system log, I have these lines that have been reported a few times tonight. Any idea what it means? I'm running v6.7.0-rc7. I have attached my diagnostic files. Apr 18 19:47:53 Tower kernel: XFS (sde1): Metadata corruption detected at xfs_buf_ioend+0x4c/0x95 [xfs], xfs_inode block 0x2550fe0 xfs_inode_buf_verify Apr 18 19:47:53 Tower kernel: XFS (sde1): Unmount and run xfs_repair Apr 18 19:47:53 Tower kernel: XFS (sde1): First 128 bytes of corrupted metadata buffer: Apr 18 19:47:53 Tower kernel: 000000004eca1978: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 18 19:47:53 Tower kernel: 0000000023f3193a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 18 19:47:53 Tower kernel: 0000000048db5825: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 18 19:47:53 Tower kernel: 00000000bd20adf2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 18 19:47:53 Tower kernel: 0000000056452f65: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 18 19:47:53 Tower kernel: 00000000c54d7f15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 18 19:47:53 Tower kernel: 00000000e84aeba6: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 18 19:47:53 Tower kernel: 000000003e6a07a7: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Apr 18 19:47:53 Tower kernel: XFS (sde1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x2550fe0 len 32 error 117 Apr 18 19:47:53 Tower kernel: XFS (sde1): xfs_imap_to_bp: xfs_trans_read_buf() returned error -117. Thank you very much for your help! tower-diagnostics-20190419-0048.zip