Menu

Can't do first sync - File number limit?

Help
lockheed
2016-09-30
2016-10-06
  • lockheed

    lockheed - 2016-09-30

    I am trying to SnapRaid my setup, but I think it is failing due to too large number of files. Here's my setup:

    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sdf2       932G   77M  932G   1% /mnt/storage_parity0
    /dev/sdd        298G   33M  298G   1% /mnt/storage_parts/samsung_320gb
    /dev/sdc        932G  661G  271G  71% /mnt/storage_parts/hitachi_1tb
    /dev/sdb        298G  296G  2.9G 100% /mnt/storage_parts/hitachi_320gb
    /dev/sde2       932G  915G   17G  99% /mnt/storage_parts/samsung_2x0.5tb_new
    

    All disks are XFS, apart form parity, which is formated with "mkfs.ext4 -m 0 -T largefile4 DEVICE"

    Now, when I try to run snapraid -v sync, every time (after deleting failed content and parity files) it ends the same:

    # snapraid -v sync
    Self test...
    Loading state from /mnt/storage_parts/samsung_2x0.5tb_new/SnapRAID.content...
    WARNING! Content file '/mnt/storage_parts/samsung_2x0.5tb_new/SnapRAID.content' not found, trying with another copy...
    Loading state from /mnt/storage_parts/hitachi_1tb/SnapRAID.content...
    WARNING! Content file '/mnt/storage_parts/hitachi_1tb/SnapRAID.content' not found, trying with another copy...
    Loading state from /mnt/storage_parts/samsung_320gb/SnapRAID.content...
    WARNING! Content file '/mnt/storage_parts/samsung_320gb/SnapRAID.content' not found, trying with another copy...
    Loading state from /var/snapraid/SnapRAID.content...
    No content file found. Assuming empty.
    Scanning disk d1...
    Excluding content '/mnt/storage_parts/samsung_2x0.5tb_new/SnapRAID.content.lock'
    Scanning disk d2...
    Scanning disk d3...
    Scanning disk d4...
           0 equal
      474483 added
           0 removed
           0 updated
           0 moved
           0 copied
           0 restored
    Using 385 MiB of memory for the FileSystem.
    Initializing...
    Saving state to /mnt/storage_parts/samsung_2x0.5tb_new/SnapRAID.content...
    Saving state to /mnt/storage_parts/hitachi_1tb/SnapRAID.content...
    Saving state to /mnt/storage_parts/samsung_320gb/SnapRAID.content...
    Saving state to /var/snapraid/SnapRAID.content...
    
    (... I cut about 200 lines just like those below...)
    
    outofparity /mnt/storage_parts/samsung_2x0.5tb_new/media/series/24/24 Season 4/24 - [4x18] - 12.00 AM - 01.00 AM.mkv
    outofparity /mnt/storage_parts/samsung_2x0.5tb_new/media/series/24/24 Season 4/24 - [4x01] - 07.00 AM - 08.00 AM..mkv
    outofparity /mnt/storage_parts/samsung_2x0.5tb_new/media/series/24/24 Season 4/24 - [4x02] - 08.00 AM - 09.00 AM.mkv
    WARNING! Without an accessible Parity file, it isn't possible to sync.
    

    I had this problem before, but after deleting one folder, it went through. However, limiting number of files is not possible anymore.

     
  • Andrea Mazzoleni

    Hi lockheed,

    The issue is that the data disks are too filled, and there isn't space in the parity for all the files marked as "outofparity". If you move them to another data disk, you should be able to sync.

    Ciao,
    Andrea

     
  • lockheed

    lockheed - 2016-10-05

    Do you mean the small 320GB disk which is full at 100%, or the large 1TB disk full at 71%? Becuase as you can see the parity disk is 1TB, so it should easily accommodate the second case.

     
  • John

    John - 2016-10-06

    The parity needs for each disk to be larger than the size of the files on that disk + overhead.

    From what I see you have less than half a million files (I assume total). This would be what, 128GB overhead even considering one snapraid default block (256 KiB) for each file (even if there's more likely half a block on the average).

    So really you shouldn't have any issue. On the other hand there was some other user reporting a week or two back some similar issue that went away when he gave up XFS (but he had it on the parity disk as well if I remember right). There might be some issue here with XFS, I don't have experience with it but it might be compression or some kind of snapshot/clones stored in it without much overhead - however presented to normal apps (like snapraid) as different files. Even if the disk is at 70% you could have (let's say) 2TB from a 1TB drive. Note that this is wild speculation.

     
  • lockheed

    lockheed - 2016-10-06

    XFS doesn't have snapshots nor compression. And the 70% space occupied is on a 932G disk, so 70% * 932G = 661G. As per the "df -h" table from the fist post.

     

Log in to post a comment.

MongoDB Logo MongoDB