Difference between revisions of "Talk:Btrfs"

From ArchWiki
Jump to: navigation, search
m (Subvol layout: Restate the question again)
(Subvol layout: re)
Line 116: Line 116:
 
::::Which fixes the issues raised elsewhere, but not the one raised here. Should the wiki be recommending a specific subvol layout when Arch refuses to recommend a partition layout?
 
::::Which fixes the issues raised elsewhere, but not the one raised here. Should the wiki be recommending a specific subvol layout when Arch refuses to recommend a partition layout?
 
::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 17:55, 14 April 2015 (UTC)
 
::::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 17:55, 14 April 2015 (UTC)
 +
 +
:The layout currently presented in [[Btrfs#Installing_Archlinux_on_btrfs]] has been suggested [http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg42856.html here]. The opposite layout of nesting the subvolumes also has its advantages, see e.g. [http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg42854.html] (same thread as the previous link). The current state is exactly as [https://bbs.archlinux.org/viewtopic.php?pid=1519185#p1519185 Scimmia says], which is not the way a wiki should present information. Not to mention that the title "Installing Archlinux on btrfs" is totally misleading -- there are many alternative layouts and the current section presents only one example. I too think that users should be able to figure out ''the best''&tmark; layout by themselves, or by consulting with upstream. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:58, 14 April 2015 (UTC)

Revision as of 17:58, 14 April 2015

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-progs 3.18 introduced 'btrfs filesystem usage' command

From the btrfs changelog [2] :

filesystem usage - give an overview of fs usage in a way that's more comprehensible than existing 'fi df'

I haven't upgraded quite yet so I don't have any sample output to post on the wiki. I'll post some info about it in Btrfs#Displaying_used.2Ffree_space when I get around to upgrading, but maybe someone will beat me to it! EscapedNull (talk) 02:06, 19 February 2015 (UTC)

Subvol layout

Recently a new section has been added called "Installing_Archlinux_on_btrfs". This section includes command by command instructions on setting things up (which is probably wrong in itself), which suggests a specific subvol layout. I don't think information like this should be in the wiki. Aside from the fact that the suggested layout causes problems, it's similar in concept to partitioning in that Arch does not want to suggest a specific layout when it really needs to be determined by the individual user's preferences and needs. Scimmia (talk) 17:17, 14 April 2015 (UTC)

again here you talk about partitioning when here we talk about subvolumes. Not the same at all. Feel free to change the wiki if you do think creating non nested subvolumes to easily manage snapshot is a bad practice.Gabx (talk)
My suggested change would be to nuke all of your recent edit. That's why I'm posting here before taking such drastic action.
Scimmia (talk) 17:30, 14 April 2015 (UTC)
Oh, and the point of the post here is that the wiki should not be suggesting specific subvol layouts. You didn't respond to that.
Scimmia (talk) 17:34, 14 April 2015 (UTC)
take any drastic measure you want on wiki. It does not belong to me. As for sublayout suggestions, I remove etc and add home and var were used as exemple. Now again feel free to change these names to MySubvolume1, MySubvolume2 etc etc. Gabx (talk)
Which fixes the issues raised elsewhere, but not the one raised here. Should the wiki be recommending a specific subvol layout when Arch refuses to recommend a partition layout?
Scimmia (talk) 17:55, 14 April 2015 (UTC)
The layout currently presented in Btrfs#Installing_Archlinux_on_btrfs has been suggested here. The opposite layout of nesting the subvolumes also has its advantages, see e.g. [3] (same thread as the previous link). The current state is exactly as Scimmia says, which is not the way a wiki should present information. Not to mention that the title "Installing Archlinux on btrfs" is totally misleading -- there are many alternative layouts and the current section presents only one example. I too think that users should be able to figure out the best&tmark; layout by themselves, or by consulting with upstream. -- Lahwaacz (talk) 17:58, 14 April 2015 (UTC)