All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: dsterba@suse.cz
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
	Donggeun Kim <dg77.kim@samsung.com>
Subject: Re: [PATCH 2/2, RFC] btrfs-progs: overhaul mkfs.btrfs -r option
Date: Thu, 07 Feb 2013 09:52:43 -0600	[thread overview]
Message-ID: <5113CDCB.7010802@redhat.com> (raw)
In-Reply-To: <20130207000812.GE12339@twin.jikos.cz>

On 2/6/13 6:08 PM, David Sterba wrote:
> On Tue, Jan 29, 2013 at 02:41:08PM -0600, Eric Sandeen wrote:
>> The manpage for the "-r" option simply says that
>> it will copy the path specified to -r into the newly
>> made filesystem.
>>
>> There's not a lot of reason to treat that option as differently
>> as it is now - today it ignores discard, fs size, and mixed
>> options, for example.  It also failed to check whether the
>> target device was mounted before proceeding.  Etc...
>>
>> Rework things so that we really follow the same paths whether
>> or not -r is specified, but with one special case for -r:
>>
>> * If the device does not exist, it will be created as
>>   a regular file of the minimum size to hold the -r path,
>>   or of size specified by the -b option.
>>
>> This also changes a little behavior; it does not pre-fill
>> the new file with zeros, but allows it to be sparse, and does
>> not truncate an existing device file.  If you want to start
>> with an empty file, just don't point it at an existing
>> file...
> 
> Fixes numerous bugs and I find the changes in behaviour sane and
> reasonable. A quick test failed for me when the image file does not
> exist:
> 
> $ rm image
> $ ./mkfs.btrfs -r . image
> ...
> not enough free space
> add_file_items failed
> unable to traverse_directory
> Making image is aborted.
> ret = -1
> mkfs.btrfs: mkfs.c:1533: main: Assertion `!(ret)' failed.
> 
> seems that the estimated size is not sufficient.

ho hum, thanks for checking.  I guess I only tried it on a very small
source directory.  For now, figuring out btrfs space usage for a given
set of files is above my pay grade and experience, I'm afraid.  :(

-Eric

> 'du' on the directory (without the image itself) gives me 59M, the image
> after failed mkfs has 102M, and it's empty when I try to mount it. Using
> the progs .git directory (18M) as sourcedir also failed, but it worked
> with man/ subdirectory (94K).
> 
> david
> 


  reply	other threads:[~2013-02-07 15:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-29 20:32 [PATCH 1/2] btrfs-progs: fix mkfs.btrfs -r option Eric Sandeen
2013-01-29 20:41 ` [PATCH 2/2, RFC] btrfs-progs: overhaul " Eric Sandeen
2013-02-07  0:08   ` David Sterba
2013-02-07 15:52     ` Eric Sandeen [this message]
2013-02-07 16:04       ` Chris Mason

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=5113CDCB.7010802@redhat.com \
    --to=sandeen@redhat.com \
    --cc=dg77.kim@samsung.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.