On Thu, Sep 30, 2010 at 3:21 PM, Daniel Lezcano <daniel.lezc...@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<gor...@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 ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users