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

[Andy Billington]

On 30/09/2010 22:10, C Anthony Risinger wrote:
> 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
>    
Also digressing, but:

In terms of what I was doing to destroy the file system, I think I can 
summarise it for you. No running containers, no open files on filesystem 
and no processes even looking at it apart from mount. Run a du -h 
against it to check something, crash.

Btrfs-tools says 0.19 as that's what came in from the apt-get. Maybe 
newer btrfs versions may work better, but until they "qualify" for an 
apt-get in Ubuntu LTS, they aren't options. ZFS on the other hand has 
been rock solid in testing in this and other scenarios for two years, so 
the problems I've had are not LXC related, they are btrfs problems with 
the current LTS version of btrfs. Maybe someone can get look at getting 
that upgraded, if there is a stable release? But, as I said, digressing ....