July 12, 20196 yr I don't think I'm understanding how the cache works or something. I have 2 1T drives in a cache pool, and the server registers that as 980G total, which is fine. My problem is my cache keeps filling up now and I appear to be missing more than 300G of storage from the cache drive. Please forgive my formatting. I don't know how to format it to be more readable, so I did the best I could. At this point, I'm thinking I may attempt to convert it to raid0, but even then I'm not sure if I'd have to empty the cache drive of its contents (which I'd like to avoid if-possible). At this point I'm looking to understand how more than 300G goes "missing" and how to get it back. Essentially am I not understanding some kind of math here, or how the cache operates or something? du -sh /mnt/cache = 600G /mnt/cache so where am I being mistaken? It seems to me that 980-600=380 and I would even allow for some overhead, but 300G?? Can someone point me in the right direction here? fdisk -l Disk /dev/sdj: 894.3 GiB, 960197124096 bytes, 1875385008 sectors Disk model: SanDisk Ultra II Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdj1 64 1875385007 1875384944 894.3G 83 Linux Disk /dev/sdk: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: SanDisk SDSSDH31 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdk1 64 1953525167 1953525104 931.5G 83 Linux btrfs fi df -H /mnt/cache Data, RAID1: total=960.20GB, used=952.02GB System, single: total=33.55MB, used=163.84kB Metadata, single: total=3.22GB, used=1.24GB GlobalReserve, single: total=245.89MB, used=0.00B btrfs fi show /mnt/cache Label: none uuid: 7a020af7-db4e-4f8f-99d8-af2616135849 Total devices 2 FS bytes used 887.79GiB devid 1 size 894.25GiB used 894.25GiB path /dev/sdj1 devid 2 size 931.51GiB used 897.28GiB path /dev/sdk1 btrfs fi usage /mnt/cache Overall: Device size: 1.78TiB Device allocated: 1.75TiB Device unallocated: 34.23GiB Device missing: 0.00B Used: 1.73TiB Free (estimated): 24.73GiB (min: 24.73GiB) Data ratio: 2.00 Metadata ratio: 1.00 Global reserve: 234.48MiB (used: 0.00B) Data,RAID1: Size:894.25GiB, Used:886.64GiB /dev/sdj1 894.25GiB /dev/sdk1 894.25GiB Metadata,single: Size:3.00GiB, Used:1.16GiB /dev/sdk1 3.00GiB System,single: Size:32.00MiB, Used:160.00KiB /dev/sdk1 32.00MiB Unallocated: /dev/sdj1 1.05MiB /dev/sdk1 34.23GiB
July 12, 20196 yr df is unreliable with btrfs, if you have Windows vdisks on cache see here to recover some space.
July 12, 20196 yr Author The size of the vm is what I expect it to be, I don't see how I'm missing those 300G. The single windows vm size on disk is 550G which is what I set it to.
July 12, 20196 yr Author It appears the instructions layed out there are specifically with Windows 8/10 in mind. In my case, my VM is Windows 7, do the same instructions apply, or would I be better served just renaming like the post mentions?
July 12, 20196 yr IIRC it won't work with Windows 7, you can use cp --sparse=always to "re-sparsify" the vdisk.
July 12, 20196 yr Author Please excuse my ignorance, I'm guessing the cp = copy meaning I'm copying the vdisk1.img? In that case, I don't have enough free space to make a duplicate copy of it, or am I misunderstanding?
July 12, 20196 yr Author ok I made a share called vmbaktemp, and since this copy is going to take a while, I just want to make sure I have my order of operations down so I'm not leaving anything out. cp /mnt/cache/vDisks/win7/vdisk1.img /mnt/user/vmbaktemp/vdisk1.img rm /mnt/cache/vDisks/win7/vdisk1.img cp --sparse=always /mnt/user/vmbaktemp/vdisk1.img /mnt/cache/vDisks/win7/vdisk1.img ...and I don't need to run any other trim commands or anything else, yes? Sorry, not trying to be a nuisance, just trying to make sure I understand the instructions properly.
July 12, 20196 yr Copying from /mnt/cache (which is a direct disk assignment) to /mnt/user (which is a user share location) can have unexpected consequences. For your specific command, you could avoid the issue by using /mnt/user0/ instead. As a general rule, don't mix disks and user shares in file operations. See here for some background of why this is so. https://forums.unraid.net/topic/32836-user-share-copy-bug/ In your specific example, if the user share vmbaktemp was defined to use cache:yes, then the copy operation would simply create the vdisk1.img file on the cache drive if your minimum free space setting wasn't set to disallow it.
July 12, 20196 yr Author crap. So did I mess things up with my copy command? If-not, I should adjust steps 2 and 3 to be /mnt/user/vDisks rather than /mnt/cache? Do my steps and syntax look correct (other than /mnt/cache)?
July 12, 20196 yr The steps you gave should actually work fine as they target different folders. The problem at has been mentioned occurs when you use the same directory on both the physical device and the user share not realising they can be two views of the same file so you copy a file on top of itself which results in it being truncated to zero size.
July 13, 20196 yr Author well that sure enough worked! thank you to everyone for the help! Will this be a reoccurring problem though? It took most of the day to copy off the img file then copy it back due to it being ~500G. Which leads me to an off-topic question, if I decided to change my cache from RAID1 to RAID0, will I need to empty off the cache drive first?
July 13, 20196 yr 2 hours ago, neztach said: Will this be a reoccurring problem though? Most likely with Win7, it's not with Win8/10 if using the procedure linked. 2 hours ago, neztach said: if I decided to change my cache from RAID1 to RAID0, will I need to empty off the cache drive first? No, it can be done online, though some free space is needed for the conversion.
Archived
This topic is now archived and is closed to further replies.