Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Roman Mamedov <rm@romanrm.net>
Cc: Vytautas D <vytdau@gmail.com>, Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Ideas for btrfs-convert fix(or rework)
Date: Thu, 12 Nov 2015 09:38:03 -0500	[thread overview]
Message-ID: <5644A44B.6050804@gmail.com> (raw)
In-Reply-To: <20151112190918.3820dd2a@natsu>

[-- Attachment #1: Type: text/plain, Size: 3256 bytes --]

On 2015-11-12 09:09, Roman Mamedov wrote:
> On Thu, 12 Nov 2015 08:27:49 -0500
> Austin S Hemmelgarn <ahferroin7@gmail.com> wrote:
>
>> know of (Arch and Gentoo), because the very fact that you installed a
>> system with either one means that you are fully capable of backing up
>> your data, and reprovisioning the system using BTRFS instead of whatever
>> filesystem you are already using
>
> Uhm, what?... How does the fact that I use one particular distro or another,
> reflect on my ability to (easily) back up and restore my 10 TB storage array?
> "You should maintain backups anyway so you could easily restore" -- yeah I do,
> and they are in a remote location over a relatively slow link.
I did not mean to imply that you had the ability to do it quickly, just 
the ability to do it.  I specifically stated 'very little' instead of 
'none' to account for cases like yours.  However, the statement is still 
accurate because Arch and Gentoo both have very low-level user 
involvement in the install process (no GUI, user manually provisions the 
storage and handles installing the base system).  If you are capable of 
installing such a system (and as such, capable of correctly using stuff 
like parted or fdisk without breaking anything), you are absolutely 
capable of reprovisioning such a system (how long that would take is a 
completely different matter).
> I chose Ext4 instead of the other options which seemed more attractive
> (primarily XFS, but also JFS) for this array back when creating it a long time
> ago, when Btrfs was still in its much earlier days than now, **SPECIFICALLY**
> with the intent to use btrfs-convert "as soon as Btrfs somewhat matures". So
> as time went, it did, I acted on this plan, and everything went just perfectly.
And you got somewhat lucky in that case (and actually did proper 
research, sadly most people don't seem to do anywhere near enough 
research when it comes to stuff like this).  Doing an in-place 
conversion of a filesystem (or an OS, or anything else for that matter) 
is _always_ going to be inherently more risk than just properly 
reprovisioning (take a look at the absolute insanity that is the 'free' 
Windows 10 upgrade for an example of this on the OS side).  Admittedly, 
compared to other software that does this (the only other program that I 
know of to do this is fstransform), btrfs-convert is relatively safe, 
but it is not possible for it to be any safer than just reprovisioning.
> Why are people so quick to project "If I don't need this, nobody likely does".
> Btrfs-convert is an amazing feature and it will be extremely sad if it ever
> goes away.
And as time goes on, it will be used less and less, and it's _always_ 
going to be something that 99% of users who actually use it (if you're 
doing any kind of RAID, it makes more sense from a data safety 
perspective to just reprovision so you can use BTRFS's native raid 
functionality) run exactly once per filesystem per system (once you've 
converted existing systems, you don't need it unless you were using dump 
for backups).  I'm not arguing that it should just go away, I'm trying 
to argue that it shouldn't be a development priority if it works correctly.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-11-12 14:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-10  6:27 Ideas for btrfs-convert fix(or rework) Qu Wenruo
2015-11-10  7:55 ` Roman Mamedov
2015-11-10  8:16   ` Qu Wenruo
2015-11-10  9:08     ` Roman Mamedov
2015-11-10  9:18       ` Qu Wenruo
2015-11-10 10:31         ` Duncan
2015-11-12 10:23           ` Vytautas D
2015-11-12 13:27             ` Austin S Hemmelgarn
2015-11-12 14:09               ` Roman Mamedov
2015-11-12 14:38                 ` Austin S Hemmelgarn [this message]
2015-11-13  6:41                   ` Duncan
2015-11-16 17:46 ` David Sterba
2015-11-17  0:42   ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5644A44B.6050804@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rm@romanrm.net \
    --cc=vytdau@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox