Talk:Btrfs

From ArchWiki
Jump to: navigation, search
Note: The name of the file system does not seem to have an official capitalization, so the rule for the ArchWiki has been arbitrarily set to use "Btrfs" (capital "B" and the rest lower-case); "btrfs" and "BTRFS" are therefore wrong spellings in this wiki. -- Kynikos (talk) 09:36, 6 January 2014 (UTC)

Things to do

Here are some items that seem to need addressing on this article. I am working on various parts of it at the moment.

  1. Reflow headings:
    1. Goals: Effective_Use_of_Headers#Use_of_headers_and_headings
      1. Helpful ideas:
        1. Effective_Use_of_Headers#False_multi-level_structure
          1. Side-note
          2. Auxiliary information
        2. Effective_Use_of_Headers#Multi-level_structure
          1. Group arguments
          2. Alternative arguments
          3. Contradictory arguments
        3. Effective_Use_of_Headers#The_header_text
        4. Article_Naming_Guidelines
          1. Specificity, "Descriptivity," Brevity, "Expandibility,"
      2. See Btrfs Wiki for ideas.
      3. See Beginners' Guide for ideas.
    2. Proposed changes
      1. "Installation" -> "Preparation"
        1. New -> "System Requirements"
        2. Remove -> "Additional packages"
          1. Move -> links to "See also" or "Related".
        3. "Partitioning" -> "Prepare the storage drive"
          1. OR: "Partitioning" (as a child) -> "Choose a partition scheme"
      2. New -> "Create file systems"
        1. "Creating a new file system" -> "New file systems"
          1. "Examples"
            1. New -> "Single-drive file systems"
            2. "Multi-device filesystem and RAID feature" -> "Multi-drive file systems"
              1. Reduce content, provide links to "Btrfs Wiki" instead.
        2. "Convert from Ext3/4" -> "Convert existing file system"
      3. New -> "Configuring the file system"
        1. OR: Move -> "Tips and tricks"
        2. Move -> "Mount options"
          1. "Copy-On-Write (CoW)" -> "Copy-on-write"
            1. "Checkpoint Interval" -> Merge
          2. Move -> "Compression"
        3. New -> "Skinny extents"
        4. Move -> "Sub-volumes"
        5. New -> "Quotas"
      4. New -> "File system management"
        1. Move -> "Balance"
        2. Move -> "Defragmentation"
        3. Move -> "Display used/free space"
        4. Move -> "Balance"
        5. Move -> "Snapshots"
      5. Move -> "Tips and tricks"
      6. New -> "Troubleshooting"
        1. Move -> "Encryption"
        2. Move -> "GRUB"
        3. Move -> "Swap file"
        4. New -> "Btrfsck"
          1. See -> https://bbs.archlinux.org/viewtopic.php?id=156100
      7. Move -> "See also"

Edits: AdamT (Talk) 08:27, 28 November 2013 (UTC); AdamT (Talk) 04:03, 29 November 2013 (UTC); AdamT (Talk) 04:10, 29 November 2013 (UTC); AdamT (Talk) 02:35, 4 December 2013 (UTC)

I hope to get to this soon if there are no objections or comments. AdamT (Talk) 20:09, 4 January 2014 (UTC)

Examples

  • Linux 3.14
    • Btrfs on a SSD for system installation and an emphasis on maximizing performance.
    noatime,compress=lzo,ssd,discard,autodefrag
    • Btrfs on a HDD for archival purposes with an emphasis on maximizing space.
    noatime,compress-force=zlib,autodefrag,nospace_cache

Why I removed the Examples section:

  • autodefrag (since 3.0): Will detect random writes into existing files and kick off background defragging. It is well suited to bdb or sqlite databases, but not virtualization images or big databases (yet). Once the developers make sure it doesn't defrag files over and over again, they'll move this toward the default.
    • Unstable, may not be what the user wants (e.g. what is stored on the HDD/SSD?)
  • compress-force=<method> - Enable compression even for files that don't compress well, like videos and dd images of disk
  • nospace_cache (since 3.2): Disable free space caching. This may slow down new writes
    • May slow down new writes.. Why would you disable free space caching? (see space_cache)

I'm sorry, but at the moment I simple not recommend to follow the examples; not that they are wrong, but simple because they differ for each user/machine.

Beta990 (talk) 23:31, 8 August 2014 (UTC)

The edit in question is [1].
Does the argument about autodefrag option apply also to "normal" foreground defragmentation, i.e. btrfs filesystem defragment?
-- Lahwaacz (talk) 07:13, 9 August 2014 (UTC)
To be honest, I don't really know. Maybe we need to contact the btrfs devs?
The bit that scares me off: 'Once the developers make sure it doesn't defrag files over and over again, they'll move this toward the default.'
Beta990 (talk) 11:04, 9 August 2014 (UTC)
It's possible I don't understand the question, but wouldn't foreground defragging be unaffected by autodefrag? I think the idea is that some applications constantly make random writes throughout their lifetimes, and Btrfs has a poor (or non-existent) algorithm for throttling defrag operations, meaning that Btrfs will constantly be starting new defrag jobs for as long as the application is running. This results in a lot of seeking and writing, and poor performance.
On-demand (foreground) defragging, on the other hand, only happens when the user requests it. This means that the file will begin to become fragmented again after the defrag has ended, until the next one. The way I see it is: use autodefrag if low seek times for reads are a requirement (sequential reads, use case: database lookup tables, row iteration), otherwise use btrfs fi defragment (as needed, or via a cron job) if one wants to save performance from the writes caused by block relocation, when sequential reads are rare (use case: mostly write-only archival data, disk images).
It really depends on the application. Does it cache lookup tables and then do random reads from there? Does it make random writes to files that are normally sequentially read? Does it simply archive data that is rarely read back? Personally I would lean towards not using autodefrag, because many applications take fragmentation into consideration from the time the file is created. For example, databases often preallocate data in large chunks to attempt to avoid fragmentation. Disk images are often preallocated to a fixed size that rarely changes. Perhaps do an on-demand defrag every now and then, just in case.
This is analogous to the "fstrim vs -o discard" debate within Btrfs and other filesystems. The discard mount option causes a discard to be dispatched every time a block is freed. This is a (sometimes?) blocking operation, meaning the filesystem has to wait for the hardware to handle the discard before moving on. In this case, it makes more sense to dispatch discards for all free blocks in batches during periods of low I/O load.
I'm by no means an expert on this, I just thought I would share my reasoning. Getting in touch with the developers definitely couldn't hurt. As for what this means to the article, I don't recommend users go overriding defaults just because they saw an options line on the wiki that claims better performance, unless they know what those options are actually doing. Defaults are defaults for a reason. EscapedNull (talk) 02:00, 19 February 2015 (UTC)

btrfs check

[Moved from ArchWiki talk:Reports#Btrfs. — Kynikos (talk) 03:39, 20 April 2015 (UTC)]

I attempted to fix the style issues reported with this edit. I'm not convinced by the idea of a 'scenario' though. I would have thought just mentioning the existence of the command, outlining its use and linking to the relevant documentation would be enough. -- Chazza (talk) 11:55, 19 April 2015 (UTC)

Subvolumes

The manpage btrf-subvolumes is really good. Do we really even need a section here about subvolumes? - Rdeckard (talk) 02:04, 31 March 2016 (UTC)