BRiT

Mine finished sometime late yesterday after I called it a night... It completely defragmented files. I'm talking 0% fragmentation! Directory fragmentation remained the same as before. Before Stats: #xfs_db -r /dev/md2 xfs_db> frag actual 17087, ideal 15986, fragmentation factor 6.44% xfs_db> frag -f actual 16522, ideal 15513, fragmentation factor 6.11% xfs_db> frag -d actual 565, ideal 473, fragmentation factor 16.28% After stats: # xfs_db -c frag -r /dev/md2 actual 16078, ideal 15986, fragmentation factor 0.57% # xfs_db -c 'frag -f' -r /dev/md2 actual 15513, ideal 15513, fragmentation factor 0.00% # xfs_db -c 'frag -d' -r /dev/md2 actual 565, ideal 473, fragmentation factor 16.28%

Mine's still running. # xfs_db -c frag -r /dev/md2 actual 16154, ideal 15986, fragmentation factor 1.04% # xfs_db -c 'frag -f' -r /dev/md2 actual 15589, ideal 15513, fragmentation factor 0.49%

As far as personal email address and accounts, I have free accounts on all the major providers, such as GMail or Outlook. As far as hosting for your own domains for yourself and others, I used to do my own domain email hosting using SendMail for a number of years (decade or more), but things became a lot easier for me when the larger mail providers started offering cheap hosting or even free hosting such as GMail.

Doing some more reading on this, and it seems you can defrag a particular file if desired. Also, you can give it a duration to run and it will only run for that long, but will produce a checkpoint file in /var/tmp/ so it can resume from that point the next time it's kicked off. I think that it only defrags files, so it might not do anything at all on directories, but I'm not certain. http://archive09.linux.com/feature/141404

Before Stats: #xfs_db -r /dev/md2 xfs_db> frag actual 17087, ideal 15986, fragmentation factor 6.44% xfs_db> frag -d actual 565, ideal 473, fragmentation factor 16.28% xfs_db> frag -f actual 16522, ideal 15513, fragmentation factor 6.11% Still in process stats: #xfs_db -r /dev/md2 xfs_db> frag actual 16297, ideal 15986, fragmentation factor 1.91% xfs_db> frag -d actual 565, ideal 473, fragmentation factor 16.28% xfs_db> frag -f actual 15732, ideal 15513, fragmentation factor 1.39%

So my drive is still defragging, well over 48 hours I believe. I wonder if it has anything to do with also running cache_dirs and not shutting it down before the defrag process.

Of my 4 data drives, only 1 of them was highly fragmented but only in the directory structure portion. That 4TB disk is 53% used at 2TB and had 17% directory fragmentation but only 6% file fragmentation. This drive is only used for TV Show episodes. I started the defrag late Thursday night (2016-02-04) and it's still going. I hope it finishes tonight.

Or some means of excluding files under a certain size or file extension as an option to exclude. This way I could exclude anything under 1 Meg which would include all the media metadata like movie.xml, movie.nfo, movie.txt, etc, since I keep metadata for xbmc/kodi, emby, pytivo, and plex.

So that seems to be 2 Official LT Dockers that have excessive size growth? Plex and BTSync.

Change the docker container itself to have that done on startup. Depending on which docker container and which base image they use will determine how to hook into that startup. You could do it on the unraid side, but why not fix what was broken where it was broken to begin with? If you're using a LinuxServer container I'm sure the fine folks there would help you out. I could also see them changing all there containers to support user adjustable startup scripts as a new feature.

Depends on your hardware. Modern SSDs have their own garbage collector threads that happen in the background when idle built into the drive itself.

Happy Holidays.

Yup. That's what I meant, just to spend tiny amount of time finding proper tools to automate things.

Perhaps look into better trools, such as automatic html to pdf conversions.

No. However, I have stopped updating the main application inside the docker containers. There is absolutely no need to be on the bleeding edge with the latest developer version of an application. I only have dockers for my immediate needs: pytivo, usenet, torrent, and an irc bot. I have not evaluated any plex or emby containers, yet. I have a working and extremely stable setup so I'm not tempted to change it. The one docker I did have major issues with was my own creation for eggdrop container where I had the daemon starting incorrectly which caused it to spam the docker log file and chew up hundreds of megs of space each day.

There have been other suggestions already earlier in this thread, involving "docker exec -it bash" and doing directory listings with "df -h" or the like. Here is one means of systematic troubleshooting, and pretty much what I used early on the 6.0 beta period to track down what my troubled containers were: 0. Remove all dockers. 1. Add a docker to your setup. 2. Observe size. 3. Use as docker container as you regularly would for 12 hours or so. 4. Restart your dockers. 4. Observe new size, if excessive grows you found a troubled container 5. If less than 3 observed times, goto step 3. 6. Goto Step 1 if more docker containers are available.

I've been running on the same docker image for close to 5 months now if not longer and it's at exactly the same size as it was when I finished adding my own docker images into it. I do not use any dockers that auto-update. I do not use any dockers that transcode inside the container. I do not use any dockers that log inside the container. I run applications of eggdrop, nzbget, transmission, and pytivo. I can guarantee there is not a bug in unRAID relating to docker images growing. If your docker image is growing it is absolutely because of a misbehaving container or a misconfigured container.

Those issues are not an unRaid defect but a defect in the particular docker container or the user's configuration of docker. As such it does not belong in the general unraid defect issue forum but in each individual docker container thread.

Anyone that uses it will likely need to have a MFT more memory, at least 16gb just to dedicate to this filesystem. If you want to run dockers and VMs you will need even more, like another 16gb. This puts min memory at 32gb for a semi useful server, with 64gb being more suitable. Everyone asking for this support, are you aware of that and does your system meet those min specs?

On a container that follows the true docker tenants, stopping and starting does not create subvolumns. However, nearly every single docker container automatically updates their program at that time. That may create new subvolumns. Those docker containers go against the fundamental premise of docker.

Thats only in play if you issue docker rm / docker rmi commands. If you never remove the images or containers then your fillup issue is caused ny something else.

I have been sitting constant at my docker usage for the past half a year. There is nothing that LT can do when users have bad behaving or misconfigured dockers. tl;dr: YOU have an issue with YOUR configuration of YOUR dockers that only YOU can fix.

If you don't delete anything from those other disks then you won't have a .Recycle.Bin in use there and it shouldn't spin up those drives.

You're likely using dockers that auto-update. Each time the main program updates in your container the image usage will grow. I do not use auto-updating programs and my docker image usage has been constant since the initial setup.