Re: BTRFS, encrypted LVM and disk write cache ?

2011-05-13 Thread Fajar A. Nugraha
On Fri, May 13, 2011 at 4:36 AM, Swâmi Petaramesh sw...@petaramesh.org wrote: However shifting from ext3 to BTRFS has been enough to turn my perfectly stable system into a perfectly unstable and crash-prone system :-/ Well, first of all, btrfs is still under heavy development. Add to that the

Re: BTRFS, encrypted LVM and disk write cache ?

2011-05-13 Thread Swâmi Petaramesh
Hi Fajar, Le vendredi 13 mai 2011 à 13:54 +0700, Fajar A. Nugraha a écrit : Well, first of all, btrfs is still under heavy development. The wiki https://btrfs.wiki.kernel.org/index.php/Main_Page says in bold: « Btrfs is under heavy development, but every effort is being made to keep the

Re: BTRFS, encrypted LVM and disk write cache ?

2011-05-13 Thread Fajar A. Nugraha
On Fri, May 13, 2011 at 3:59 PM, Swâmi Petaramesh sw...@petaramesh.org wrote: Adding to the fact that it comes included with the stock and distro kernels... That gives a bit contradictory signals... Should I stay or should I go ? Looks a bit like legal babble boiling down to « Yes, it is

Re: BTRFS, encrypted LVM and disk write cache ?

2011-05-13 Thread Swâmi Petaramesh
Le vendredi 13 mai 2011 à 16:16 +0700, Fajar A. Nugraha a écrit : IIRC 2.6.38 has a bug in that you can't use mount option subvol=... if the fs/subvolume is newly created, while 2.6.39 works fine. At least that's what I experienced, so now I use subvolid to select subvolume. # uname -a Linux

Re: BTRFS, encrypted LVM and disk write cache ?

2011-05-13 Thread Fajar A. Nugraha
On Fri, May 13, 2011 at 4:33 PM, Swâmi Petaramesh sw...@petaramesh.org wrote: # uname -a Linux tethys 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux # mount | grep btrfs /dev/mapper/VG1-TETHYS on / type btrfs (rw,relatime,subvol=UBUNTU,compress=zlib)

Re: BTRFS, encrypted LVM and disk write cache ?

2011-05-13 Thread Swâmi Petaramesh
Le vendredi 13 mai 2011 à 16:16 +0700, Fajar A. Nugraha a écrit : if you encounter problems try to use latest available kernel for Natty first. If it doesn't work, try latest vanilla kernel from kernel.org. When I was younger I used to spend days compiling and installing and testing things,

Re: [PATCH v3 3/3] btrfs: quasi-round-robin for chunk allocation

2011-05-13 Thread David Sterba
Hi, here are my comments, after first review round, mostly on code itself, not the functionality/quality of the allocator (although after this patch the allocator code looks quite straightforward a better to read and understand). Reviewing the patch directly does not work, Arne's advice was to

Re: [PATCH] btrfs: quasi-round-robin for chunk allocation

2011-05-13 Thread David Sterba
Hi, On Mon, Apr 11, 2011 at 01:46:33PM -0400, Chris Mason wrote: My big complaint about this patch is that it is a feature fix mixed in with a huge cleanup. It's hard to differentiate between the two. Could you please separate it out so we can review them independently? I agree that changes

[PATCH v4 0/3] btrfs: quasi-round-robin for chunk allocation

2011-05-13 Thread Arne Jansen
In a multi device setup, the chunk allocator currently always allocates chunks on the devices in the same order. This leads to a very uneven distribution, especially with RAID1 or RAID10 and an uneven number of devices. This patch always sorts the devices before allocating, and allocates the

[PATCH v4 2/3] btrfs: heed alloc_start

2011-05-13 Thread Arne Jansen
currently alloc_start is disregarded if the requested chunk size is bigger than (device size - alloc_start), but smaller than the device size. The only situation where I see this could have made sense was when a chunk equal the size of the device has been requested. This was possible as the

[PATCH v4 1/3] btrfs: move btrfs_cmp_device_free_bytes to super.c

2011-05-13 Thread Arne Jansen
this function won't be used here anymore, so move it super.c where it is used for df-calculation Signed-off-by: Arne Jansen sensi...@gmx.net --- fs/btrfs/super.c | 26 ++ fs/btrfs/volumes.c | 13 - fs/btrfs/volumes.h | 15 --- 3 files

[PATCH v4 3/3] btrfs: quasi-round-robin for chunk allocation

2011-05-13 Thread Arne Jansen
In a multi device setup, the chunk allocator currently always allocates chunks on the devices in the same order. This leads to a very uneven distribution, especially with RAID1 or RAID10 and an uneven number of devices. This patch always sorts the devices before allocating, and allocates the

BTRFS memory usage

2011-05-13 Thread Swâmi Petaramesh
Hi, I was wondering about BTRFS memory needs. For example ZFS is known to have a huge memory footprint, so it is not advisable on systems with little RAM. I was wondering about BTRFS, and couldn't find anything in the FAQ... TIA. -- To unsubscribe from this list: send the line unsubscribe

Re: kernel BUG at fs/btrfs/inode.c:149!

2011-05-13 Thread whirm
On Thursday 05 May 2011 20:57:17 Josef Bacik wrote: [..] It doesn't look like that bit had my debugging output. Thanks, Josef Looks like the last message I sent didn't make to the list. Here's the link to the debug log: http://pastebin.com/raw.php?i=fnfsnVZS Thanks, -- Elric Milon --

[PATCH] Btrfs: load the key from the dir item in readdir into a fake dentry

2011-05-13 Thread Josef Bacik
Ok so if your name is Christoph Hellwig or Al Viro, please point a video camera at your face and start recording before reading further. Once you are done please upload to youtube because I imagine the expressions on your faces will be epic. In btrfs we have 2 indexes for inodes. One is for

[PATCH] Btrfs: check for duplicate entries in the free space cache

2011-05-13 Thread Josef Bacik
If there are duplicate entries in the free space cache, discard the entire cache and load it the old fashioned way. Thanks, Signed-off-by: Josef Bacik jo...@redhat.com --- fs/btrfs/free-space-cache.c | 27 --- 1 files changed, 24 insertions(+), 3 deletions(-) diff

Re: Understanding DF, etc.

2011-05-13 Thread Helmut Hullen
Hallo, Swâmi, Du meintest am 13.05.11: I have trouble understanding this, which doesn't really correspond to the wiki FAQ (so my question is hopefully not a FAQ ;-) : # btrfs fi df / Data: total=74.01GB, used=72.77GB System, DUP: total=8.00MB, used=16.00KB System: total=4.00MB, used=0.00

[RFC][PATCH 1/2] vfs: allow /proc/pid/maps to return a custom device

2011-05-13 Thread Mark Fasheh
This patch introduces a callback in the super_operations structure, 'get_maps_dev' which is then used by procfs to query which device to return for reporting in /proc/[PID]/maps. btrfs wants this so that it can return the same device as it uses from stat(2) calls. Signed-off-by: Mark Fasheh

[RFC][PATCH 2/2] Subject: btrfs: Introduce btrfs_get_maps_dev()

2011-05-13 Thread Mark Fasheh
Use this to return the subvolume superblock in proc instead of the global superblock which is automatically taken today. This fixes a userspace breakage where discrepancies between the devices two would confuse software such as lsof. Signed-off-by: Mark Fasheh mfas...@suse.com ---

Re: [TEST] test the seek_hole/seek_data functionality

2011-05-13 Thread Sunil Mushran
On 05/05/2011 01:16 PM, Josef Bacik wrote: This is my very rough tester for testing seek_hole/seek_data. Please look over it and make sure we all agree that the semantics are correct. My btrfs patch passes with this and ext3 passes as well. I still have to added fallocate() to it, but for now