From: Chris Mason <chris.mason@oracle.com>
To: Kyungmin Park <kmpark@infradead.org>
Cc: Donggeun Kim <dg77.kim@samsung.com>,
linux-btrfs@vger.kernel.org, kyungmin.park@samsung.com
Subject: Re: [PATCH] btrfs: Add a new mount option to grow the FS to the limit of the device
Date: Wed, 4 Aug 2010 10:52:42 -0400 [thread overview]
Message-ID: <20100804145242.GI16630@think> (raw)
In-Reply-To: <AANLkTinCTLrz1cV9hutttvYe4K2VsNUjmD+tT4X2DFW5@mail.gmail.com>
On Wed, Aug 04, 2010 at 10:56:18PM +0900, Kyungmin Park wrote:
> On Wed, Aug 4, 2010 at 10:47 PM, Chris Mason <chris.mason@oracle.com>=
wrote:
> > On Wed, Aug 04, 2010 at 10:45:00PM +0900, Kyungmin Park wrote:
> >> On Wed, Aug 4, 2010 at 10:30 PM, Chris Mason <chris.mason@oracle.c=
om> wrote:
> >> > On Wed, Aug 04, 2010 at 08:34:43PM +0900, Donggeun Kim wrote:
> >> >> Chris Mason wrote:
> >> >> > On Mon, Aug 02, 2010 at 05:42:00PM +0900, Donggeun Kim wrote:
> >> >> >> In some cases, resizing a file system to the maximum device =
size is required.
> >> >> >> When flashing a file system image to a block device,
> >> >> >> the file system does not fit into the block device's size.
> >> >> >> Currently, executing 'btrfsctl' application is the only way
> >> >> >> to grow the file system to the limit of the device.
> >> >> >> If the mount option which alters the device size of a file s=
ystem
> >> >> >> to the limit of the device is supported,
> >> >> >> it can be useful regardless of the existence of 'btrfsctl' p=
rogram.
> >> >> >> This patch allows the file system to grow to the maximum siz=
e of the device
> >> >> >> on mount time.
> >> >> >> The new mount option name is 'maxsize'.
> >> >> >
> >> >> > I think this is a very useful feature, but could you please c=
hange the
> >> >> > patch to allow controlling which device is resized?
> >> >> >
> >> >> > The ioctl allows you to pass in a device number (where the nu=
mber comes
> >> >> > from btrfs-show)
> >> >> >
> >> >> > Thanks!
> >> >> >
> >> >> > -chris
> >> >> >
> >> >> I'm sorry not to fully understand your comment.
> >> >> Do you mean that device file name for being resized is specifie=
d after 'maxsize' mount option?
> >> >> e.g) #mount -o maxsize=3D/dev/sda1 ...
> >> >
> >> > In the resize ioctl you can pass a device number, something like=
2:max,
> >> > which allows you to say make device #2 the full size of the devi=
ce.
> >> >
> >> > btrfs-show can be used to find the correct device number for a g=
iven
> >> > disk. =A0We don't use the device name because the scan might hav=
e found a
> >> > different device name to tie into the FS.
> >> >
> >> > Thanks,
> >> > Chris
> >>
> >> Before comments this issues. I first explain why this feature impl=
emented.
> >>
> >> As you know, we implement the build image from some specific
> >> directory. the size is maybe small than designed devices. e.g., bu=
ild
> >> image got the 400MiB but real device size has more the 8GiB.
> >> after program the btrfs image, then it will be expanded at first b=
oot only.
> >
> > Yes, and this makes a lot of sense to me. =A0I can see how the patc=
h fits
> > your usage and that you don't need the extra flag to pick a device =
on
> > mounting.
> >
> >>
> >> Initial draft design is that add the some flag at build image. the=
n it
> >> checks it at first mount time. and expand to device size.
> >> But after some study we know that btrfs supports resize feature. S=
o we
> >> implement it as patch.
> >> Anyway that's our requirement.
> >>
> >> as you provided usage, can you use the ioctl to achieve this
> >> requirement? if not, we need to another method.
> >
> > Yes, the ioctl can currently pick a device to resize. =A0In your ca=
se,
> > there will only be one device and this isn't an issue. =A0But, I'd =
like to
> > see parity between what the mount option can do and what the ioctl =
can
> > do, just so we are a little more consistent.
> >
>=20
> Then when call the ioctl? in the phone. the boot script is almost
> fixed. and not easy to check first boot.
> Mr. Kim said the check real size happen every time at mount if apply
> patch. but it don't take time if it's already expanded. I think ioctl
> has also same problem. if we use this method.
> I don't want to call ioctl at every boot time. does it just my hope?
Sorry, I didn't explain this very well.
Right now you have mount -o maxsize /dev/xxx
I'd like to keep that functionality unchanged, but make it possible to
also do:
mount -o maxsize=3D2 /dev/xxxx
Which would extend only device id 2.
This would keep similar functionality to what the ioctl can do, but
still let you do it at mount time. Does this make more sense?
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2010-08-04 14:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 8:42 [PATCH] btrfs: Add a new mount option to grow the FS to the limit of the device Donggeun Kim
2010-08-03 11:49 ` Chris Mason
2010-08-04 11:34 ` Donggeun Kim
2010-08-04 13:30 ` Chris Mason
2010-08-04 13:45 ` Kyungmin Park
2010-08-04 13:47 ` Chris Mason
2010-08-04 13:56 ` Kyungmin Park
2010-08-04 14:52 ` Chris Mason [this message]
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=20100804145242.GI16630@think \
--to=chris.mason@oracle.com \
--cc=dg77.kim@samsung.com \
--cc=kmpark@infradead.org \
--cc=kyungmin.park@samsung.com \
--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 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).