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
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
---
fs/btrfs/super.c |6 ++
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
---
I originally posted about this issue some weeks ago but unfortunately didn't
get a response:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/9682
To recap:
btrfs_getattr() is filling stat->dev with an anonymous device
(for per-snapshot root?):
stat->dev = BTRFS_I(inode)->root->anon_sup
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=
On 05/13/2011 01:19 PM, wh...@gmx.com wrote:
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:
So unfortunately I don't
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
---
fs/btrfs/free-space-cache.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/fre
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 read
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
--
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 linux
Our readahead is sort of sloppy, and really isn't always needed. For example if
ls is doing a stating ls (which is the default) it's going to stat in non-disk
order, so if say you have a directory with a stupid amount of files, readahead
is going to do nothing but waste time in the case of doing t
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
stripe
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
---
fs/btrfs/super.c | 26 ++
fs/btrfs/volumes.c | 13 -
fs/btrfs/volumes.h | 15 ---
3 files changed, 26 insertions
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 allocat
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
stripe
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 chang
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 lo
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, a
Hi list,
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
Metadata, DUP: total=1.75GB, used=657.
On Fri, May 13, 2011 at 4:33 PM, Swâmi Petaramesh 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)
> /dev/mapper/V
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
On Fri, May 13, 2011 at 3:59 PM, Swâmi Petaramesh 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 supposed to
> work
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 files
23 matches
Mail list logo
