{"id":13495984,"url":"https://github.com/kdave/btrfsmaintenance","last_synced_at":"2025-12-29T22:19:23.315Z","repository":{"id":21530799,"uuid":"24850077","full_name":"kdave/btrfsmaintenance","owner":"kdave","description":"Scripts for btrfs maintenance tasks like periodic scrub, balance, trim or defrag on selected mountpoints or directories.","archived":false,"fork":false,"pushed_at":"2024-07-04T18:17:01.000Z","size":154,"stargazers_count":881,"open_issues_count":36,"forks_count":76,"subscribers_count":36,"default_branch":"master","last_synced_at":"2024-08-01T19:57:26.738Z","etag":null,"topics":["administration","btrfs"],"latest_commit_sha":null,"homepage":null,"language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kdave.png","metadata":{"files":{"readme":"README.man","changelog":"CHANGES.md","contributing":"CONTRIBUTING.md","funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2014-10-06T14:49:40.000Z","updated_at":"2024-08-01T18:30:41.000Z","dependencies_parsed_at":"2022-07-15T23:46:07.135Z","dependency_job_id":"5f4070a4-bcf3-4263-9851-918a47ffa95e","html_url":"https://github.com/kdave/btrfsmaintenance","commit_stats":null,"previous_names":[],"tags_count":11,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kdave%2Fbtrfsmaintenance","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kdave%2Fbtrfsmaintenance/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kdave%2Fbtrfsmaintenance/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kdave%2Fbtrfsmaintenance/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kdave","download_url":"https://codeload.github.com/kdave/btrfsmaintenance/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":222402848,"owners_count":16978747,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["administration","btrfs"],"created_at":"2024-07-31T19:01:40.405Z","updated_at":"2025-12-29T22:19:18.279Z","avatar_url":"https://github.com/kdave.png","language":"Shell","funding_links":[],"categories":["Shell","HarmonyOS","Install from Source"],"sub_categories":["Windows Manager","Snapshots Management/System Recovery"],"readme":".nh\n.TH Btrfs maintenance toolbox\n.PP\nTable of contents:\n\n.RS\n.IP \\(bu 2\nQuick start\n\\[la]#quick-start\\[ra]\n.IP \\(bu 2\nDistro integration\n\\[la]#distro-integration\\[ra]\n.IP \\(bu 2\nTuning periodic snapshotting\n\\[la]#tuning-periodic-snapshotting\\[ra]\n\n.RE\n\n.PP\nThis is a set of scripts supplementing the btrfs filesystem and aims to automate\na few maintenance tasks. This means the \\fIscrub\\fP, \\fIbalance\\fP, \\fItrim\\fP or\n\\fIdefragmentation\\fP\\\u0026.\n\n.PP\nEach of the tasks can be turned on/off and configured independently. The\ndefault config values were selected to fit the default installation profile\nwith btrfs on the root filesystem.\n\n.PP\nOverall tuning of the default values should give a good balance between effects\nof the tasks and low impact of other work on the system. If this does not fit\nyour needs, please adjust the settings.\n\n.SH Tasks\n.PP\nThe following sections will describe the tasks in detail. There's one config\noption that affects the task concurrency, \\fB\\fCBTRFS\\_ALLOW\\_CONCURRENCY\\fR\\\u0026. This is\nto avoid extra high resource consumption or unexpected interaction among the\ntasks and will serialize them in the order they're started by timers.\n\n.SS scrub\n.PP\n\\fBDescription:\\fP Scrub operation reads all data and metadata from the devices\nand verifies the checksums. It's not mandatory, but may point out problems with\nfaulty hardware early as it touches data that might not be in use and bit rot.\n\n.PP\nIf there's a redundancy of data/metadata, ie. the \\fIDUP\\fP or \\fIRAID1/5/6\\fP profiles, scrub\nis able to repair the data automatically if there's a good copy available.\n\n.PP\n\\fBImpact when active:\\fP Intense read operations take place and may slow down or\nblock other filesystem activies, possibly only for short periods.\n\n.PP\n\\fBTuning:\\fP\n\n.RS\n.IP \\(bu 2\nthe recommended period is once in a month but a weekly period is also acceptable\n.IP \\(bu 2\nyou can turn off the automatic repair (\\fB\\fCBTRFS\\_SCRUB\\_READ\\_ONLY\\fR)\n.IP \\(bu 2\nthe default IO priority is set to \\fIidle\\fP but scrub may take long to finish,\nyou can change priority to \\fInormal\\fP (\\fB\\fCBTRFS\\_SCRUB\\_PRIORITY\\fR)\n\n.RE\n\n.PP\n\\fBRelated commands:\\fP\n\n.RS\n.IP \\(bu 2\nyou can check status of last scrub run (either manual or through the cron\njob) by \\fB\\fCbtrfs scrub status /path\\fR\n.IP \\(bu 2\nyou can cancel a running scrub anytime if you find it inconvenient (\\fB\\fCbtrfs\nscrub cancel /path\\fR), the progress state is saved each 5 seconds and next\ntime scrub will start from that point\n\n.RE\n\n.SS balance\n.PP\n\\fBDescription:\\fP The balance command can do a lot of things, in general moves\ndata around in big chunks. Here we use it to reclaim back the space of the\nunderused chunks so it can be allocated again according to current needs.\n\n.PP\nThe point is to prevent some corner cases where it's not possible to eg.\nallocate new metadata chunks because the whole device space is reserved for all\nthe chunks, although the total space occupied is smaller and the allocation\nshould succeed.\n\n.PP\nThe balance operation needs enough workspace so it can shuffle data around. By\nworkspace we mean device space that has no filesystem chunks on it, not to be\nconfused by free space as reported eg. by \\fB\\fCdf\\fR\\\u0026.\n\n.PP\n\\fBImpact when active:\\fP Possibly big. There's a mix of read and write operations, is\nseek\\-heavy on rotational devices. This can interfere with other work in case\nthe same set of blocks is affected.\n\n.PP\nThe balance command uses filters to do the work in smaller batches.\n\n.PP\nBefore kernel version 5.2, the impact with quota groups enabled can be extreme.\nThe balance operation performs quota group accounting for every extent being\nrelocated, which can have the impact of stalling the file system for an\nextended period of time.\n\n.PP\n\\fBExpected result:\\fP If possible all the underused chunks are removed, the\nvalue of \\fB\\fCtotal\\fR in output of \\fB\\fCbtrfs fi df /path\\fR should be lower than before.\nCheck the logs.\n\n.PP\nThe balance command may fail with \\fIno space\\fP reason but this is considered a\nminor fault as the internal filesystem layout may prevent the command to find\nenough workspace. This might be a time for manual inspection of space.\n\n.PP\n\\fBTuning:\\fP\n\n.RS\n.IP \\(bu 2\nyou can make the space reclaim more aggressive by adding higher percentage to\n\\fB\\fCBTRFS\\_BALANCE\\_DUSAGE\\fR or \\fB\\fCBTRFS\\_BALANCE\\_MUSAGE\\fR\\\u0026. Higher value means bigger\nimpact on your system and becomes very noticeable.\n.IP \\(bu 2\nthe metadata chunks usage pattern is different from data and it's not\nnecessary to reclaim metadata block groups that are more than 30 full. The\ndefault maximum is 10 which should not degrade performance too much but may\nbe suboptimal if the metadata usage varies wildly over time. The assumption\nis that underused metadata chunks will get used at some point so it's not\nabsolutely required to do the reclaim.\n.IP \\(bu 2\nthe useful period highly depends on the overall data change pattern on the\nfilesystem\n\n.RE\n\n.PP\n\\fBChanged defaults since 0.5:\\fP\n\n.PP\nVersions up to 0.4.2 had usage filter set up to 50% for data and up to 30% for\nmetadata.  Based on user feedback, the numbers have been reduced to 10% (data)\nand 5% (metadata). The system load during the balance service will be smaller\nand the result of space compaction still reasonable. Multiple data chunks filled\nto less than 10% can be merged into fewer chunks. The file data can change in\nlarge volumes, eg. deleting a big file can free a lot of space. If the space is\nleft unused for the given period, it's desirable to make it more compact.\nMetadata consumption follows a different pattern and reclaiming only the almost\nunused chunks makes more sense, otherwise there's enough reserved metadata\nspace for operations like reflink or snapshotting.\n\n.PP\nA convenience script is provided to update the unchanged defaults,\n\\fB\\fC/usr/share/btrfsmaintenance/update\\-balance\\-usage\\-defaults.sh\\fR .\n\n.SS trim\n.PP\n\\fBDescription:\\fP The TRIM operation (aka. \\fIdiscard\\fP) can instruct the underlying device to\noptimize blocks that are not used by the filesystem. This task is performed\non\\-demand by the \\fIfstrim\\fP utility.\n\n.PP\nThis makes sense for SSD devices or other type of storage that can translate\nthe TRIM action to something useful (eg. thin\\-provisioned storage).\n\n.PP\n\\fBImpact when active:\\fP Should be low, but depends on the amount of blocks\nbeing trimmed.\n\n.PP\n\\fBTuning:\\fP\n\n.RS\n.IP \\(bu 2\nthe recommended period is weekly, but monthly is also fine\n.IP \\(bu 2\nthe trim commands might not have an effect and are up to the device, eg. a\nblock range too small or other constraints that may differ by device\ntype/vendor/firmware\n.IP \\(bu 2\nthe default configuration is \\fIoff\\fP because of the the system fstrim.timer\n\n.RE\n\n.SS defrag\n.PP\n\\fBDescription:\\fP Run defragmentation on configured directories. This is for\nconvenience and not necessary as defragmentation needs are usually different\nfor various types of data.\n\n.PP\nPlease note that the defragmentation process does not descend to other mount\npoints and nested subvolumes or snapshots. All nested paths would need to be\nenumerated in the respective config variable. The command utilizes \\fB\\fCfind\n\\-xdev\\fR, you can use that to verify in advance which paths will the\ndefragmentation affect.\n\n.PP\n\\fBSpecial case:\\fP\n\n.PP\nThere's a separate defragmentation task that happens automatically and\ndefragments only the RPM database files. This is done via a \\fIzypper\\fP plugin\nand the defrag pass triggers at the end of the installation.\n\n.PP\nThis improves reading the RPM databases later, but the installation process\nfragments the files very quickly so it's not likely to bring a significant\nspeedup here.\n\n.SH Periodic scheduling\n.PP\nThere are now two ways how to schedule and run the periodic tasks: cron and\nsystemd timers. Only one can be active on a system and this should be decided\nat the installation time.\n\n.SS Cron\n.PP\nCron takes care of periodic execution of the scripts, but they can be run any\ntime directly from \\fB\\fC/usr/share/btrfsmaintenance/\\fR, respecting the configured\nvalues in \\fB\\fC/etc/sysconfig/btrfsmaintenance\\fR\\\u0026.\n\n.PP\nThe changes to configuration file need to be reflected in the \\fB\\fC/etc/cron\\fR\ndirectories where the scripts are linked for the given period.\n\n.PP\nIf the period is changed, the cron symlinks have to be refreshed:\n\n.RS\n.IP \\(bu 2\nmanually \\-\\- use \\fB\\fCsystemctl restart btrfsmaintenance\\-refresh\\fR (or the \\fB\\fCrcbtrfsmaintenance\\-refresh\\fR shortcut)\n.IP \\(bu 2\nin \\fIyast2\\fP \\-\\- sysconfig editor triggers the refresh automatically\n.IP \\(bu 2\nusing a file watcher \\-\\- if you install \\fB\\fCbtrfsmaintenance\\-refresh.path\\fR, this will utilize the file monitor to detect changes and will run the refresh\n\n.RE\n\n.SS Systemd timers\n.PP\nThere's a set of timer units that run the respective task script. The periods\nare configured in the \\fB\\fC/etc/sysconfig/btrfsmaintenance\\fR file as well. The\ntimers have to be installed using a similar way as cron.  Please note that the\n'\\fI\\\u0026.timer' and respective '\\fP\\\u0026.service' files have to be installed so the timers\nwork properly.\n\n.PP\nSome package managers (eg. \\fB\\fCapt\\fR) will configure the timers automatically at\ninstall time \\- you can check with \\fB\\fCls /usr/lib/systemd/system/btrfs*\\fR\\\u0026.\n\n.PP\nTo install the timers manually, run \\fB\\fCbtrfsmaintenance\\-refresh\\-cron.sh timer\\fR\\\u0026.\n\n.SH Quick start\n.PP\nThe tasks' periods and other parameters should fit most use cases and do not\nneed to be touched. Review the mount points (variables ending with\n\\fB\\fC\\_MOUNTPOINTS\\fR) whether you want to run the tasks there or not.\n\n.SH Distro integration\n.PP\nCurrently the support for widely used distros is present.  More distros can be\nadded. This section describes how the pieces are put together and should give\nsome overview.\n\n.SS Installation\n.PP\nFor debian based systems, run \\fB\\fCdist\\-install.sh\\fR as root.\n\n.PP\nFor non\\-debian based systems, check for distro provided package or\ndo manual installation of files as described below.\n\n.RS\n.IP \\(bu 2\n\\fB\\fCbtrfs\\-*.sh\\fR task scripts are expected at \\fB\\fC/usr/share/btrfsmaintenance\\fR\n.IP \\(bu 2\n\\fB\\fCsysconfig.btrfsmaintenance\\fR configuration template is put to:\n.RS\n.IP \\(bu 2\n\\fB\\fC/etc/sysconfig/btrfsmaintenance\\fR on SUSE and RedHat based systems or derivatives\n.IP \\(bu 2\n\\fB\\fC/etc/default/btrfsmaintenance\\fR on Debian and derivatives\n\n.RE\n\n.IP \\(bu 2\n\\fB\\fC/usr/lib/zypp/plugins/commit/btrfs\\-defrag\\-plugin.sh\\fR or\n\\fB\\fC/usr/lib/zypp/plugins/commit/btrfs\\-defrag\\-plugin.py\\fR post\\-update script for\nzypper (the package manager), applies to SUSE\\-based distros for now\n.IP \\(bu 2\ncron refresh scripts are installed (see bellow)\n\n.RE\n\n.PP\nThe defrag plugin has a shell and python implementation, choose what suits the\ninstallation better.\n\n.SS cron jobs\n.PP\nThe periodic execution of the tasks is done by the 'cron' service.  Symlinks to\nthe task scripts are located in the respective directories in\n\\fB\\fC/etc/cron.\u003cPERIOD\u003e\\fR\\\u0026.\n\n.PP\nThe script \\fB\\fCbtrfsmaintenance\\-refresh\\-cron.sh\\fR will synchronize the symlinks\naccording to the configuration files. This can be called automatically by a GUI\nconfiguration tool if it's capable of running post\\-change scripts or services.\nIn that case there's \\fB\\fCbtrfsmaintenance\\-refresh.service\\fR systemd service.\n\n.PP\nThis service can also be automatically started upon any modification of the\nconfiguration file in \\fB\\fC/etc/sysconfig/btrfsmaintenance\\fR by installing the\n\\fB\\fCbtrfsmaintenance\\-refresh.path\\fR systemd watcher.\n\n.SS Post\\-update defragmentation\n.PP\nThe package database files tend to be updated in a random way and get\nfragmented, which particularly hurts on btrfs. For rpm\\-based distros this means files\nin \\fB\\fC/var/lib/rpm\\fR\\\u0026. The script or plugin simply runs a defragmentation on the affected files.\nSee \\fB\\fCbtrfs\\-defrag\\-plugin.sh\\fR or \\fB\\fCbtrfs\\-defrag\\-plugin.py\\fR for more details.\n\n.PP\nAt the moment the 'zypper' package manager plugin exists. As the package\nmanagers differ significantly, there's no single plugin/script to do that.\n\n.SS Settings\n.PP\nThe settings are copied to the expected system location from the template\n(\\fB\\fCsysconfig.btrfsmaintenance\\fR). This is a shell script and can be sourced to obtain\nvalues of the variables.\n\n.PP\nThe template contains descriptions of the variables, default and possible\nvalues and can be deployed without changes (expecting the root filesystem to be\nbtrfs).\n\n.SH Tuning periodic snapshotting\n.PP\nThere are various tools and handwritten scripts to manage periodic snapshots\nand cleaning. The common problem is tuning the retention policy constrained by\nthe filesystem size and not running out of space.\n\n.PP\nThis section will describe factors that affect that, using snapper\n\\[la]https://snapper.io\\[ra]\nas an example, but adapting to other tools should be straightforward.\n\n.SS Intro\n.PP\nSnapper is a tool to manage snapshots of btrfs subvolumes. It can create\nsnapshots of given subvolume manually, periodically or in a pre/post way for\na given command. It can be configured to retain existing snapshots according\nto time\\-based settings. As the retention policy can be very different for\nvarious use cases, we need to be able to find matching settings.\n\n.PP\nThe settings should satisfy user's expectation about storing previous copies of\nthe subvolume but not taking too much space. In an extreme, consuming the whole\nfilesystem space and preventing some operations to finish.\n\n.PP\nIn order to avoid such situations, the snapper settings should be tuned according\nto the expected use case and filesystem size.\n\n.SS Sample problem\n.PP\nDefault settings of snapper on default root partition size can easily lead to\nno\\-space conditions (all TIMELINE values set to 10). Frequent system updates\nmake it happen earlier, but this also affects long\\-term use.\n\n.SS Factors affecting space consumption\n.RS\n.IP \"  1.\" 5\nfrequency of snapshotting\n.IP \"  2.\" 5\namount of data changes between snapshots (delta)\n.IP \"  3.\" 5\nsnapshot retention settings\n.IP \"  4.\" 5\nsize of the filesystem\n\n.RE\n\n.PP\nEach will be explained below.\n\n.PP\nThe way how the files are changed affects the space consumption. When a new\ndata overwrite existing, the new data will be pinned by the following snapshot,\nwhile the original data will belong to previous snapshot.  This means that the\nallocated file blocks are freed after the last snapshot pointing to them is\ngone.\n\n.SS Tuning\n.PP\nThe administrator/user is supposed to know the approximate use of the partition\nwith snapshots enabled.\n\n.PP\nThe decision criteria for tuning is space consumption and we're optimizing to\nmaximize retention without running out of space.\n\n.PP\nAll the factors are intertwined and we cannot give definite answers but rather\ndescribe the tendencies.\n\n.SS Snapshotting frequency\n.RS\n.IP \\(bu 2\n\\fBautomatic\\fP: if turned on with the \\fB\\fCTIMELINE\\fR config option, the periodic\nsnapshots are taken hourly. The daily/weekly/monthly/yearly periods will keep\nthe first hourly snapshot in the given period.\n.IP \\(bu 2\n\\fBat package update\\fP: package manager with snapper support will create\npre/post snapshots before/after an update happens.\n.IP \\(bu 2\n\\fBmanual\\fP: the user can create a snapshot manually with \\fB\\fCsnapper create\\fR,\nwith a given snapshot type (ie. single, pre, post).\n\n.RE\n\n.SS Amount of data change\n.PP\nThis is a parameter hard to predict and calculate. We work with rough\nestimates, eg. megabytes, gigabytes etc.\n\n.SS Retention settings\n.PP\nThe user is supposed to know possible needs of recovery or examination of\nprevious file copies stored in snapshots.\n\n.PP\nIt's not recommended to keep too old snapshots, eg. monthly or even yearly if\nthere's no apparent need for that. The yearly snapshots should not substitute\nbackups, as they reside on the same partition and cannot be used for recovery.\n\n.SS Filesystem size\n.PP\nBigger filesystem allows for longer retention, higher frequency updates and\namount of data changes.\n\n.PP\nAs an example of a system root partition, the recommended size is 30 GiB, but\n50 GiB is selected by the installer if the snapshots are turned on.\n\n.PP\nFor non\\-system partition it is recommended to watch remaining free space.\nAlthough getting an accurate value on btrfs is tricky, due to shared extents\nand snapshots, the output of \\fB\\fCdf\\fR gives a rough idea. Low space, like under a\nfew gigabytes is more likely to lead to no\\-space conditions, so it's a good\ntime to delete old snapshots or review the snapper settings.\n\n.SS Typical use cases\n.SS A rolling distro\n.RS\n.IP \\(bu 2\nfrequency of updates: high, multiple times per week\n.IP \\(bu 2\namount of data changed between updates: high\n\n.RE\n\n.PP\nSuggested values:\n\n.PP\n.RS\n\n.nf\nTIMELINE\\_LIMIT\\_HOURLY=\"12\"\nTIMELINE\\_LIMIT\\_DAILY=\"5\"\nTIMELINE\\_LIMIT\\_WEEKLY=\"2\"\nTIMELINE\\_LIMIT\\_MONTHLY=\"1\"\nTIMELINE\\_LIMIT\\_YEARLY=\"0\"\n\n.fi\n.RE\n\n.PP\nThe size of root partition should be at least 30GiB, but more is better.\n\n.SS Regular/enterprise distro\n.RS\n.IP \\(bu 2\nfrequency of updates: low, a few times per month\n.IP \\(bu 2\namount of data changed between updates: low to moderate\n\n.RE\n\n.PP\nMost data changes come probably from the package updates, in the range of\nhundreds of megabytes per update.\n\n.PP\nSuggested values:\n\n.PP\n.RS\n\n.nf\nTIMELINE\\_LIMIT\\_HOURLY=\"12\"\nTIMELINE\\_LIMIT\\_DAILY=\"7\"\nTIMELINE\\_LIMIT\\_WEEKLY=\"4\"\nTIMELINE\\_LIMIT\\_MONTHLY=\"6\"\nTIMELINE\\_LIMIT\\_YEARLY=\"1\"\n\n.fi\n.RE\n\n.SS Big file storage\n.RS\n.IP \\(bu 2\nfrequency of updates: moderate to high\n.IP \\(bu 2\namount of data changed between updates: no changes in files, new files added, old deleted\n\n.RE\n\n.PP\nSuggested values:\n\n.PP\n.RS\n\n.nf\nTIMELINE\\_LIMIT\\_HOURLY=\"12\"\nTIMELINE\\_LIMIT\\_DAILY=\"7\"\nTIMELINE\\_LIMIT\\_WEEKLY=\"4\"\nTIMELINE\\_LIMIT\\_MONTHLY=\"6\"\nTIMELINE\\_LIMIT\\_YEARLY=\"0\"\n\n.fi\n.RE\n\n.PP\nNote, that deleting a big file that has been snapshotted will not free the space\nuntil all relevant snapshots are deleted.\n\n.SS Mixed\n.RS\n.IP \\(bu 2\nfrequency of updates: unpredictable\n.IP \\(bu 2\namount of data changed between updates: unpredictable\n\n.RE\n\n.PP\nExamples:\n\n.RS\n.IP \\(bu 2\nhome directory with small files (in range of kilobytes to megabytes), large files (hundreds of megabytes to gigabytes).\n.IP \\(bu 2\ngit trees, bare and checked out repositories\n\n.RE\n\n.PP\nNot possible to suggest config numbers as it really depends on user\nexpectations. Keeping a few hourly snapshots should not consume too much space\nand provides a copy of files, eg. to restore after accidental deletion.\n\n.PP\nStarting point:\n\n.PP\n.RS\n\n.nf\nTIMELINE\\_LIMIT\\_HOURLY=\"12\"\nTIMELINE\\_LIMIT\\_DAILY=\"7\"\nTIMELINE\\_LIMIT\\_WEEKLY=\"1\"\nTIMELINE\\_LIMIT\\_MONTHLY=\"0\"\nTIMELINE\\_LIMIT\\_YEARLY=\"0\"\n\n.fi\n.RE\n\n.SS Summary\n.TS\nallbox;\nl l l l l l \nl l l l l l .\n\\fB\\fCType\\fR\t\\fB\\fCHourly\\fR\t\\fB\\fCDaily\\fR\t\\fB\\fCWeekly\\fR\t\\fB\\fCMonthly\\fR\t\\fB\\fCYearly\\fR\nRolling\t12\t5\t2\t1\t0\nRegular\t12\t7\t4\t6\t1\nBig files\t12\t7\t4\t6\t0\nMixed\t12\t7\t1\t0\t0\n.TE\n\n.SH About\n.PP\nThe goal of this project is to help administering btrfs filesystems. It is not\nsupposed to be distribution specific. Common scripts/configs are preferred but\nper\\-distro exceptions will be added when necessary.\n\n.PP\nLicense: GPL 2\n\\[la]https://www.gnu.org/licenses/gpl-2.0.html\\[ra]\n\n.PP\nContributing guide\n\\[la]CONTRIBUTING.md\\[ra]\\\u0026.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkdave%2Fbtrfsmaintenance","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkdave%2Fbtrfsmaintenance","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkdave%2Fbtrfsmaintenance/lists"}