On Fri, Oct 30, 2009 at 11:24 AM, Josef Bacik jo...@redhat.com wrote:
On Fri, Oct 30, 2009 at 09:48:55AM +0800, Yan, Zheng wrote:
On Fri, Oct 30, 2009 at 4:35 AM, Josef Bacik jo...@redhat.com wrote:
If there are alot of snapshots we could conceivably end up using much more
metadata space
I'm trying to make this snapshots/subvolumes listing feature,
I wonder how the interface should be.
I tried to make this feature using ioctl interface, but I don't
know how to notify all subvolume informations because number
of subvolumes are not known before search.
(It may work, that we call
Discard the whole device before starting to create the filesystem structures.
Modelled after similar support in mkfs.xfs.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: btrfs-progs-unstable/utils.c
===
---
Hi,
the results of running 'df' against a btrfs volume are somewhat
unintuitive from a user point of view. On a single drive btrfs volume,
created with 'mkfs.btrfs -m raid1 -d raid1 /dev/sda6', I am getting
the following result:
/dev/sda6 1.4T 594G 804G 43% /mnt
while
On Fri, Oct 30, 2009 at 01:02:44AM -0400, Christoph Hellwig wrote:
On Thu, Oct 29, 2009 at 09:52:15PM +0100, Andi Drebes wrote:
As recently discussed on the list, btrfsck should only be run on unmounted
filesystems. This patch adds a short check for the mount status at the
beginning of
Leszek Ciesielski wrote:
Hi,
the results of running 'df' against a btrfs volume are somewhat
unintuitive from a user point of view. On a single drive btrfs volume,
created with 'mkfs.btrfs -m raid1 -d raid1 /dev/sda6', I am getting
the following result:
/dev/sda6 1.4T 594G 804G
On 10/26/2009 05:14 AM, Chris Mason wrote:
On Fri, Oct 23, 2009 at 02:08:48PM -0400, Jeff Mahoney wrote:
On 10/22/2009 06:15 AM, Andi Drebes wrote:
I don't know what is the developer plan to fix that - apparently it's
not in the high-priority list (but it must be certainly in the priority
Hi!
Quite a bit of time i'm watching in chromium strange behavior when
downloading files - after like 2Mb of any download it starts hdd
thrashing(with hdd noise/lots of seeks or the like). After some
research and seeing like no one else experiencing this i tried to
switch ~/.cache/chromium to
On Fri, Oct 30, 2009 at 09:27:36AM -0400, Jeff Mahoney wrote:
On 10/26/2009 05:14 AM, Chris Mason wrote:
On Fri, Oct 23, 2009 at 02:08:48PM -0400, Jeff Mahoney wrote:
On 10/22/2009 06:15 AM, Andi Drebes wrote:
I don't know what is the developer plan to fix that - apparently it's
not in
This patch fixes a problem where max_size can be set to 0 even though we
filled the cluster properly. We set max_size to 0 if we restart the cluster
window, but if the new start entry is big enough to be our new cluster then we
could return with a max_size set to 0, which will mean the next time
10 matches
Mail list logo
