Talk:Btrfs
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (
~~~~), and indent successive comments with colons (:).
Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.Still unstable?
"While it's true that btrfs is still considered experimental and unstable, [...]"
As far as I know btrfs is stable since April 2013 and is used by some other distros. How about changing this part?
-- MeikoDis (talk) 15:10, 6 March 2014 (UTC)
- Although I don't disagree, links to prove your point would help. :) You do know anyone with a wiki account can update this article, right? --Maffblaster (talk) 16:53, 25 August 2015 (UTC)
Minimum size for boot partititon
This article says "/boot requires 280 megs or more." Where does this requirement come from? Any source?
- No idea. This comment is out of place and doesn't make much sense. I have removed it. --Tamiko (talk) 15:52, 22 September 2016 (UTC)
Rolling back back from snapshots
I think It would be important to include a way to roll back root subvolume to a state before catastrophe or what not bad situation. I know aproximately how to do that. But if there's someone who knows and has done suck roll back and is willing to write some lines about it, please make it so. ;) --Zucca (talk) 20:43, 11 May 2017 (UTC)
Expand conversion section
I believe that there are 2 important things not mentioned:
- btrfs-convert creates a rollback subvolume that can be deleted when the conversion is considered stable (ref: man btrfs-convert).
- It is also recommended that a balance -m be run after the conversion itself, although not mandatory (ref: man btrfs-convert)
Any thoughts? I'm happy to make the changes unless there is any reasonable argument against this.
--Gabrielg (talk) 08:37, 25 May 2020 (UTC)
Nodatacow recommendation
In the Troubleshooting section "Using with VM disk images" It says it is recommended to use nodatacow (chattr +C). I think some more details about how this affects performance should be mentioned. It is also important to mention that nodatacow removes checksums, a very important part of Btrfs. It degrades integrity.
Gatak (talk) 12:12, 14 July 2020 (UTC)
- I think these are standard considerations mentioned somewhere in the btrfs wiki. Interestingly, I think the most relevant feature that you lose with nodatacow is that you can't snapshot, so you can't make backups via snapshots, so you have to implement a different method (qemu has CoW images for example, and a snapshot could be saved in a CoW file, presumably). The data integrity you make reference to is just metadata - theoretically the whole VM image will become unreadable if a small amount of it is corrupted, prompting you to restore from a backup.
Gabrielg (talk) 12:26, 16 December 2020 (UTC)
kernel and btrfs-progs version parity
It seems advisable to suggest to users that they ought to keep parity between their btrfs-progs and their kernel, as observed in IRC chats, some bug comments and at least personal experience.
For example, if you run a non-LTS 5.9.x kernel, you want to also run unstable btrfs-progs-5.9. This isn't critical for most operations but could cause issues that an "on par" btrfs-progs package won't.
Needless to say, this shouldn't be a problem for stable users.
Thoughts against making this suggestion?