File distribution not optimal. How to see which file(s) are affected?

[MikeRotch]

Hello.  Been a Drivepool user for a few years now.  I have a question after a recent file balancing pass gave me a message I don't know how to resolve.  I have received this message over the last week.

I am getting: 

File distribution not optimal.
Files could not be moved to satisfy file placement rules (12 B ) during the last balancing pass.

What does 12 B mean? 12 Bytes or rule 12 B?

Nothing has changed on my system.  According to the usage graph, they all look only about 70% full.  The drives range from 8-18TB so there are many TBs of room available on some of the drive and I do not have files that are multi-TB in size.  The landing zone is an SSD that I have only unduplicated files allowed and in the rules I have SSD optimizer set.  How can I see which files are the ones that can't be balanced?

EDIT: Ok, I went into the balancing settings and this error came up:

StableBit DrivePool
Unable to enumerate folder.

Access is denied

I guess that would be the reason why file(s) couldn't be balanced.  Somehow a permission got changed on a folder and/or files.  The question still remains the same, how can I see the affected files/folders.

 

[Shane]

It would mean 12 bytes.

You could try opening the service log (cog icon -> troubleshooting) and then repeat going into the balancing settings to see if the problem folder is indicated, or the saved service logs in "C:\ProgramData\StableBit DrivePool\Service\Logs\Service\".

I would suggest trying the fixes in the following thread: https://community.covecube.com/index.php?/topic/5810-ntfs-permissions-and-drivepool/ 

 

[MikeRotch]

Thanks for the reply.

I was able to look through my logs and found the entry that says "access is denied".  I found the associated volume GUID with those entries.  But when I look up the GUID for my drives using diskpart, sel disk (I've gone through all my desk numbers), uniqueid disk, I can't find the GUID from the DrivePool log.  

from the log:

'\\?\Volume{513fb597-d833-4b9a-8731-09b4ed8d58ab}\PoolPart.be5392c5-a8ff-4a00-8aae-16eaa84a6cdc\murmur.log'. Access is denied    2024-07-19 09:04:50Z    6558400055150

I can't find 513fb597-d833-4b9a-8731-09b4ed8d58ab or 5392c5-a8ff-4a00-8aae-16eaa84a6cdc using uniqueid disk.
 

[MikeRotch]

Applied some more Google-Fu and found this command

GWMI -namespace root\cimv2 -class win32_volume | FL -property DriveLetter, DeviceID

which gave me different GUIDs than from diskpart.  I was able to match the volume from the logs to the GUIDs provided by that command.  I think I have corrected the permissions from https://community.covecube.com/index.php?/topic/5810-ntfs-permissions-and-drivepool/ 

and will try a balancing pass.

Thanks again,

[MikeRotch]

Ok, so I was on vacation and didn't get a chance to reply.

I am still experiencing the same issue.  In the logs I do not get any more access denied errors.  In fact, I do not get any more errors that I can see.  What can I search for in the logs regarding these 12 Bytes?  Heh.

 

[Shane]

Manually, I suppose one could look for any 12 byte files that are in a poolpart drive other than one where your File Placement rules say it should be placed (e.g. I know Voidtools' Everything utility can use size:12B as a search term) and then try moving it yourself to the "correct" poolpart and running a Remeasure.

@Christopher (Drashna) any ideas where to look in the Service log or file logs?

[MikeRotch]

Thanks for the reply.  So luckily I already have Everything (LOVE this tool) on my server and did a search.  There are 0 hits of 12B files on the DrivePool drive (drive D).  

[Shane]

Just in case, note that while Everything will detect a DrivePool pool as a NTFS volume, it won't see any files in it as DrivePool's NTFS emulation doesn't include what Everything needs to parse it; you can either use Everything to search via the underlying poolpart drives or add your pool under Everything's Options -> Indexes -> Folders.

But your screenshot and checking my own pools gives me a clue; check your File Placement rules to see if "D:\System Volume Information" (where D is the letter of your pool drive) has any rules set on it - if it or any subfolders have a green symbol it needs to be reverted to default (all drives checked, New drives unchecked, Overflow allowed, 90%); go to File Placement -> Rules and see if there is anything there that might be influencing it.

If that's not the case, you may need to delete your "D:\System Volume Information" folder (where D is the drive letter of your pool). This is somewhat involved:

• Open the Properties of the folder. Click on Security and then Advanced.
• Choose "Change" to change the current owner.
• Enter the exact username of your administrator account (you must already be logged in as that account).
• Tick to Replace owner on subcontainers and objects.
• OK; confirm that you're replacing the directory permissions.
• Open a command prompt run as Administrator.
• Use the following command: rmdir "D:\System Volume Information" /s /q
  (where D is the the letter of your pool)
• It should run without giving you an Access Denied message.
• Restart your computer.

[MikeRotch]

The issue seemed to resolve itself.  I did not have any rules set on D:\System Volume Information.  But I didn't have to do the troubleshooting steps you recommended either.

This is very strange.  Anyway, thanks for all your help.