[Lxc-users] Container Filesystem in a file (loopback mount)

[C Anthony Risinger]

On Thu, Sep 30, 2010 at 3:21 PM, Daniel Lezcano <daniel.lezcano at free.fr> wrote:
> On 09/30/2010 09:50 PM, Andy Billington wrote:
>> On 30/09/2010 20:21, C Anthony Risinger wrote:
>>
>>> On Thu, Sep 30, 2010 at 8:05 AM, Gordon Henderson<gordon at drogon.net>   wrote:
>>>
>>>
>>>> On Thu, 30 Sep 2010, Daniel Lezcano wrote:
>>>>
>>>>
>>>>
>>>>> On 09/30/2010 11:04 AM, Gordon Henderson wrote:
>>>>>
>>>>>
>>>>>> Looking to put "hard" limits on a containers filesystem size by creating a
>>>>>> fixed-length file, putting a filesystem in it, loopback mounting it, then
>>>>>> using that as the containers root ...
>>>>>>
>>>>>> I've not tried it yet, but wondering if anyone has done anything like
>>>>>> this? Any pitfalls? (Other than maybe performance)
>>>>>>
>>>>>>
>>>>> Yep, I tried, no problem.
>>>>>
>>>>>
>>>> Great.
>>>>
>>>>
>>>>
>>>>> In a near future, we will be able to specify directly the image in
>>>>> lxc.rootfs. The code doing that is ready but there are some problems with the
>>>>> consoles I have to fix before.
>>>>>
>>>>>
>>>> Sounds good, thanks!
>>>>
>>>>
>>> in the past i used a btrfs filesystem, and put each system in a
>>> subvolume; this let me create templates that were instantly cloneable,
>>> and able to run within seconds.
>>>
>>> IIRC, you can't do this right now, but soon you will be able to place
>>> quotas on the subvolumes.  also, you can snapshot them the make a
>>> backup instantly.  just a suggestion, it worked extremely well.
>>>
>>> C Anthony
>>>
>>>
>>>
>> I've been experimenting with btrfs and cloning this afternoon; once I'd
>> got over an unrecoverable btrfs error and loss of all test data, it
>> worked fairly smoothly. I wasn't using subvolumes or playing with quotas
>> though, so not sure that helps this discussion :) With a few bits of
>> easy scripting, creating new systems and starting them up was taking
>> tens of  seconds; backups quicker - on a desktop PC, with the LXC host
>> running inside a VMware virtual machine. The experience of losing an
>> entire filesystem due to a btrfs fault though means I don't think it's a
>> sensible route to take at this point .......
>>
>
> Yeah, btrfs is still experimental. In the past, I did the same as
> Anthony without visible problems but when I tried recently I crashed my
> filesystem too. I am very impatient to see btrfs more mature because it
> looks very promising.

yeah i guess i wouldn't use it for clients at this point, but with
build in raid/compression/etc. its a really sweet deal when combined
w/LXC, so something to keep in mind, as i don't think it will be long
until you will start seeing it everywhere.

in my case i was running several personal containers, and other
temporary stuff.  btrfs made excellent use of the disk space, as every
dom was COW'ed from a template.

while developing some tools to quickly create containers, i literally
created and destroyed hundreds of containers (btrfs) without problems.
 i also use it on several machines, including this laptop, which has
had a btrfs / since .31, again without any issue whatsoever.

i'm digressing though, but i don't know what people are doing to
destroy their filesystems as i have done a tremendous amount of work
and tinkering, and have yet to ruin one... maybe i'm just lucky though
:-).  the btrfs list is pretty quiet; i think most are using it rather
successfully.

C Anthony