On 12/14/2014 10:06 PM, Robert White wrote:
On 12/14/2014 05:21 PM, Dongsheng Yang wrote:
Anyone have some suggestion about it?
(... strong advocacy for raw numbers...)
Concise Example to attempt to be clearer:
/dev/sda == 1TiB
/dev/sdb == 2TiB
/dev/sdc == 3TiB
/dev/sdd == 3TiB
mkfs.btrfs /
Hi, thanks for the answer, I will answer between the lines.
On 15.12.2014 08:45, Robert White wrote:
> On 12/14/2014 08:50 PM, Nick Dimov wrote:
>> Hello everyone!
>>
>> First, thanks for amazing work on btrfs filesystem!
>>
>> Now the problem:
>> I use a ssd as my system drive (/dev/sda2) and use
On 12/14/2014 08:50 PM, Nick Dimov wrote:
Hello everyone!
First, thanks for amazing work on btrfs filesystem!
Now the problem:
I use a ssd as my system drive (/dev/sda2) and use daily snapshots on
it. Then, from time to time, i sync those on HDD (/dev/sdb4) by using
btrfs send / receive like th
It seems the second patch, which about 225K including a btrfs-image
dump, can't pass the ml's size limit.
To David:
I created the pull request to your github repo:
https://github.com/kdave/btrfs-progs/pull/3
Thanks,
Qu
Original Message
Subject: [PATCH 1/2] btrfs-progs: Add su
On 12/14/2014 05:21 PM, Dongsheng Yang wrote:
Does it make sense to you?
I understood what you were saying but it didn't make sense to me...
As there are 2 complaints for the same change of @size in df, I have to
say it maybe not so easy to understand.
Anyone have some suggestion about it
Hello everyone!
First, thanks for amazing work on btrfs filesystem!
Now the problem:
I use a ssd as my system drive (/dev/sda2) and use daily snapshots on
it. Then, from time to time, i sync those on HDD (/dev/sdb4) by using
btrfs send / receive like this:
ionice -c3 btrfs send -p /ssd/previousl
Although btrfsck test case support pure image dump(tar.xz), it is still
too large for some images, e.g, a small 64M image with about 3 levels
(level 0~2) metadata will produce about 2.6M after xz zip, which is too
large for a single binary commit.
However btrfs-image -c9 will works much finer, the
Original Message
Subject: Re: [PATCH v4 00/13] btrfs-progs:fsck: Add inode nlink mismatch and
From: Qu Wenruo
To: dste...@suse.cz, Filipe David Manana ,
linux-btrfs@vger.kernel.org
Date: 2014年12月15日 09:25
The binary image dump is definitely working, but the size still seems
The binary image dump is definitely working, but the size still seems
not so good :-(
For my case, 64M contains my /etc copy even after xz with -9 option, the
size is still about 2.8M. (although
xz is already doing great job).
I know there is even larger btrfs-image dump case here, but sev
On 12/14/2014 10:32 PM, Grzegorz Kowal wrote:
Hi,
I see another problem on 1 device fs after applying this patch. I set
up 30GB system partition:
in gdisk key 'i'
Partition size: 62914560 sectors (30.0 GiB) -> 62914560 * 512 =
32212254720 = 30.0GiB
before applying the patch df -B1 shows
Files
On 11 December 2014 at 12:37, Holger Hoffstätte
wrote:
>
> David,
>
> I was wondering if you could please send out announcements for btrfs-progs
> when you tag a release or -rc? There doesn't seem to be a good mechanism
> to track releases and IMHO the more people are notified, the more
> testing
Hi,
I see another problem on 1 device fs after applying this patch. I set
up 30GB system partition:
in gdisk key 'i'
Partition size: 62914560 sectors (30.0 GiB) -> 62914560 * 512 =
32212254720 = 30.0GiB
before applying the patch df -B1 shows
Filesystem1B-blocks UsedAvailable
On Sat, Dec 13, 2014 at 3:25 AM, Goffredo Baroncelli wrote:
> On 12/11/2014 09:31 AM, Dongsheng Yang wrote:
>> When function btrfs_statfs() calculate the tatol size of fs, it is
>> calculating
>> the total size of disks and then dividing it by a factor. But in some
>> usecase,
>> the result is n
On 12/13/2014 03:56 PM, Robert White wrote:
...
Dangit... On re-reading I think I was still less than optimally clear. I
kept using the word "resent" when I should have been using a word like
"re-written" or "re-stored" (as opposed to "restored"). On re-reading
I'm not sure what the least co
14 matches
Mail list logo