linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org, dsterba@suse.cz
Subject: Re: [PATCH v3 07/14] btrfs-progs: Doc/mkfs: Add extra condition for rootdir option
Date: Fri, 22 Sep 2017 07:38:15 -0400	[thread overview]
Message-ID: <9f598cb9-0267-158d-c54b-13f4372eadd5@gmail.com> (raw)
In-Reply-To: <trinity-eef9a61f-60ab-47a3-9771-d638cb0083c9-1506076766926@3c-app-mailcom-bs16>

On 2017-09-22 06:39, Qu Wenruo wrote:
> As I already stated in an other thread, if you want to shrink, do it in another command line tool.
> Do one thing and do it simple. (Although Btrfs itself is already out of the UNIX way)
Unless I'm reading the code wrong, the shrinking isn't happening in a 
second pass, so this _is_ doing one thing, and it appears to be doing it 
as simply as possible (although arguably not correctly because of the 
1MB reserved area being used).
> 
> It may be offline shrink/balance. But not to further complexing the --rootdir option now. >
> And you also said that, the shrink feature is not a popular feature *NOW*, then I don't think it's worthy to implment it *NOW* either.
> Implement future feature in the future please.
I'm not sure about you, but I could have sworn that he meant seed 
devices weren't a popular feature right now, not that the shrinking is. 
As a general rule, the whole option of pre-loading a filesystem with 
data as you're creating it is not a popular feature, because most 
sysadmins are much more willing to trust adding data after the 
filesystem is created.

Personally, given the existence of seed devices, I would absolutely 
expect there to be a quick and easy way to generate a minimalistic image 
using a single command (because realistic usage of seed devices implies 
minimalistic images).  I agree that it shouldn't be the default 
behavior, but I don't think it needs to be removed completely.  The main 
issues here are that it wasn't documented well (like many other things 
in BTRFS), and it didn't generate a filesystem that was properly 
compliant with the on-disk format (because it used space in the 1MB 
reserved area at the beginning of the FS).  Fixing those issues in no 
way requires removing the feature.
> 
> And further more, even following the existing shrink behavior, you still need to truncate the file all by yourself.
> Which is no better than creating a good sized file and then mkfs on it.
Only if you pre-create the file.  If the file doesn't exist, it gets 
created at the appropriate size.  That's part of why the chunk 
allocations are screwed up and stuff gets put in the first 1MB, it 
generates the FS on-the-fly and writes it out as it's generating it.
> 
> Thanks,
> Qu
> 
> Sent: Friday, September 22, 2017 at 5:24 PM
> From: "Anand Jain" <anand.jain@oracle.com>
> To: "Qu Wenruo" <quwenruo.btrfs@gmx.com>, linux-btrfs@vger.kernel.org
> Cc: dsterba@suse.cz
> Subject: Re: [PATCH v3 07/14] btrfs-progs: Doc/mkfs: Add extra condition for rootdir option
> 
>> +WARNING: Before v4.14 btrfs-progs, *--rootdir* will shrink the filesystem,
>> +prevent user to make use of the remaining space.
>> +In v4.14 btrfs-progs, this behavior is changed, and will not shrink the fs.
>> +The result should be the same as `mkfs`, `mount` and then `cp -r`. +
> 
> Hmm well. Shrink to fit exactly to the size of the given
> files-and-directory is indeed a nice feature. Which would help to create
> a golden-image btrfs seed device. Its not popular as of now, but at some
> point it may in the cloud environment.
> 
> Replacing this feature instead of creating a new option is not a good
> idea indeed. I missed something ?
> 
> Thanks, Anand
> 
>> +Also, if destination file/block device does not exist, *--rootdir* will not
>> +create the image file, to make it follow the normal mkfs behavior.


  reply	other threads:[~2017-09-22 11:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-18  7:21 [PATCH v3 00/14] Mkfs: Rework --rootdir to a more generic behavior Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 01/14] btrfs-progs: Refactor find_next_chunk() to get rid of parameter root and objectid Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 02/14] btrfs-progs: Fix one-byte overlap bug in free_block_group_cache Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 03/14] btrfs-progs: mkfs: Rework rootdir option to avoid custom chunk layout Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 04/14] btrfs-progs: mkfs: Update allocation info before verbose output Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 05/14] btrfs-progs: Avoid BUG_ON for chunk allocation when ENOSPC happens Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 06/14] btrfs-progs: mkfs: Workaround BUG_ON caused by rootdir option Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 07/14] btrfs-progs: Doc/mkfs: Add extra condition for " Qu Wenruo
2017-09-22  9:24   ` Anand Jain
2017-09-22 10:39     ` Qu Wenruo
2017-09-22 11:38       ` Austin S. Hemmelgarn [this message]
2017-09-22 12:32         ` Qu Wenruo
2017-09-22 13:33           ` Austin S. Hemmelgarn
2017-09-22 15:07             ` Qu Wenruo
2017-09-24 10:10               ` Anand Jain
2017-09-24 14:08                 ` Goffredo Baroncelli
2017-09-25 11:15                   ` Austin S. Hemmelgarn
2017-09-27 16:20                     ` David Sterba
2017-09-28  0:00                       ` Qu Wenruo
2017-09-29 11:30                         ` Austin S. Hemmelgarn
2017-09-29 16:57                         ` Goffredo Baroncelli
2017-09-30  3:33                           ` Qu Wenruo
2017-10-02 11:47                             ` Austin S. Hemmelgarn
2017-10-02 18:47                               ` Goffredo Baroncelli
2017-09-25 11:53               ` Austin S. Hemmelgarn
2017-09-18  7:21 ` [PATCH v3 08/14] btrfs-progs: tests/common: Split user xattr into its own branch for generate_dataset Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 09/14] btrfs-progs: tests/common: Introduce optional parameter to specify destination directory " Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 10/14] btrfs-progs: tests/common: Make checksum, permission and acl check path independent Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 11/14] btrfs-progs: tests/mkfs: Add basic test case for rootdir parameter Qu Wenruo
2017-09-18  7:35   ` [PATCH v3.1 " Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 12/14] btrfs-progs: tests/common: Detect ungraceful failure case Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 13/14] btrfs-progs: mkfs: Fix overwritten return value for mkfs Qu Wenruo
2017-09-18  7:21 ` [PATCH v3 14/14] btrfs-progs: tests/mkfs: Check error handler for rootdir parameter 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=9f598cb9-0267-158d-c54b-13f4372eadd5@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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;
as well as URLs for NNTP newsgroup(s).