Hallo, Phillip,
Du meintest am 30.11.11:
>> You start with a system of 2 disks. They get filled nearly
>> simultaneously.
>> Then you add a 3rd disk (which is empty at that time). Now it's a
>> good idea to run "balance" for equalizing the filling.
> balance != resize
I know.
p.e.
Start with 1
On 11/30/2011 12:17 AM, David Sterba wrote:
> On Tue, Nov 29, 2011 at 09:18:35AM +0800, Liu Bo wrote:
>> a) For the first one (last_snapshot bug),
>>
>> The test involves three processes (derived from Chris):
>>
>> mkfs.btrfs /dev/xxx
>> mount /dev/xxx /mnt
>>
>> 1) run compilebench -i 30 --makej -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/30/2011 01:59 PM, Helmut Hullen wrote:
> Hallo, Phillip,
>
> Du meintest am 30.11.11:
>
>> Currently the resize command is under filesystem, and takes a path to
>> the mounted filesystem. This seems wrong to me. Shouldn't it be
>> under devic
On Nov 29, 2011, Christian Brunner wrote:
> When I'm doing havy reading in our ceph cluster. The load and wait-io
> on the patched servers is higher than on the unpatched ones.
That's unexpected.
> This seems to be coming from "btrfs-endio-1". A kernel thread that has
> not caught my attention
I plugged it directly by sata and this is what I get from the 3.1 kernel:
[ 577.850429] ata3: exception Emask 0x10 SAct 0x0 SErr 0x405
action 0xe frozen
[ 577.850433] ata3: irq_stat 0x0040, connection status changed
[ 577.850436] ata3: SError: { PHYRdyChg CommWake DevExch }
[ 577.85044
Hallo, Roman,
Du meintest am 01.12.11:
> Okay, adding a new device wasn't the best example to explain my
> point.
> What I meant is resizing a BTRFS partition, enlarging it or shrinking
> it as needed, while still on the same device.
That's no good example, too.
btrfs allows to bundle several
On Thursday, 01 December, 2011 02:07:30 you wrote:
[...]
> Resizing in both 'directions' seems to work very well on single-device BTRFS
> filesystems, and also it's very useful that BTRFS is almost the only modern
> FS (besides ext4) that can be shrinked. But with multi-device filesystems,
> don't
I'm hitting an error with the default mkfs.btrfs in debian wheezy:
ford:~# uname -a
Linux ford.blinkenlights.nl 3.1.0-1-kirkwood #1 Tue Nov 15 00:17:24 UTC
2011 armv5tel GNU/Linux
ford:~/btrfs-progs# dpkg -l | grep btrfs
ii btrfs-tools 0.19+2005-1
Checksumming Co
On 30 Nov 2011 20:43:00 +0100
"Helmut Hullen" wrote:
> Hallo, Roman,
>
> Du meintest am 01.12.11:
>
> > What if I need to replace an individual device with a smaller or a
> > larger one?
>
> 1) add the new device
> 2) balance (may be it's not necessary)
> 3) run "remove" for the "individual" d
Hallo, Roman,
Du meintest am 01.12.11:
> What if I need to replace an individual device with a smaller or a
> larger one?
1) add the new device
2) balance (may be it's not necessary)
3) run "remove" for the "individual" device
4) remove it
5) balance
Viele Gruesse!
Helmut
--
To unsubscribe from
On Thursday, 01 December, 2011 01:15:47 you wrote:
> On 30 Nov 2011 19:59:00 +0100
>
> "Helmut Hullen" wrote:
> > > Currently the resize command is under filesystem, and takes a path
> > > to
> > > the mounted filesystem. This seems wrong to me. Shouldn't it be
> > > under device, and take a pa
On 30 Nov 2011 19:59:00 +0100
"Helmut Hullen" wrote:
> > Currently the resize command is under filesystem, and takes a path to
> > the mounted filesystem. This seems wrong to me. Shouldn't it be
> > under device, and take a path to a device to resize?
>
> No - it's a filesystem operation.
Are
Hallo, Phillip,
Du meintest am 30.11.11:
> Currently the resize command is under filesystem, and takes a path to
> the mounted filesystem. This seems wrong to me. Shouldn't it be
> under device, and take a path to a device to resize?
No - it's a filesystem operation.
p.e.
You start with a sys
Currently the resize command is under filesystem, and takes a path to the
mounted filesystem. This seems wrong to me. Shouldn't it be under device, and
take a path to a device to resize? Otherwise, how can a resize operation when
you have multiple devices make any sense?
--
To unsubscribe fr
Now that we're properly keeping track of delayed inode space we've been getting
a lot of warnings out of btrfs_dirty_inode() when running xfstest 83. This is
because a bunch of people call mark_inode_dirty, which is void so we can't
return ENOSPC. This needs to be fixed in a few areas
1) file_up
On Tue, Nov 29, 2011 at 09:26:01AM +0800, Li Zefan wrote:
> This patch has the same problem with your previous one, that it will set
> f_bavail to 0. I've sent out a new patch yesterday.
Ahh, sounds great thanks. Often a patch is a good way to start a
discussion to a more correct patch. Special
On Tue, Nov 29, 2011 at 05:44:12PM -0800, Keith Mannthey wrote:
> Gracefully fail when trying to mount a BTRFS file system that has a
> sectorsize smaller than PAGE_SIZE.
>
> On PPC it is possible to build a FS while using a 4k PAGE_SIZE kernel
> then boot into a 64K PAGE_SIZE kernel. Presently
On Wed, Nov 30, 2011 at 11:30:01AM +0100, Arne Jansen wrote:
> On 29.11.2011 22:47, Chris Mason wrote:
> > On Tue, Nov 29, 2011 at 09:40:56PM +0100, Arne Jansen wrote:
> >> Write bios are submitted from the submit_worker. The worker pumps down
> >> bios into the block layer until it signals a conge
On Wed, Nov 30, 2011 at 10:44:15AM +0100, Tobias wrote:
> Am 28.11.2011 10:29, schrieb Chris Samuel:
> >Hi Tobias,
> >
> >On Mon, 28 Nov 2011, 19:16:25 EST, Tobias wrote:
> >
> >>The problem occurs on the stock ubuntu kernel 2.6.38-8, 3.0.0-12,
> >>3.0.0-13 and on my self-compiled 3.1.2.
> >There'
On Fri, Nov 25, 2011 at 10:40:00AM +, 810d4rk wrote:
> > My mistake, the same printks are printed when the encryption key is
> > incorrect, I've seen that here.
> > It looks like you have some ugly hardware errors.
> > The kernel cannot read from the drive, so it cannot guess the file system
Is anyone able to reproduce the problems that I described? I can help
if anyone is interested.
> The hard drive is brand new, I also plugged it directly via eSATA and
> checked the SMART data and run some tests and it succeeded in all, if
> I format the drive again I have a working file-system for
Currently when mounting a btrfs filesystem a user searching dmesg
has no obvious string to search for as currently we report something
cryptic like:
[ 5775.216078] device label DR devid 1 transid 15757 /dev/sdh1
It would be much nicer if there was some mention of btrfs to find
(as other filesyste
Currently there are 3 different capitalisations of btrfs: used in
printk()'s, BTRFS: (3 occurences), Btrfs: (1 occurence) and btrfs:
(77 occurences).
It's best to have them all the same for consistency, so we canonicalise
the two minority cases to btrfs:.
Signed-off-by: Chris Samuel
---
fs/btrf
On Wed, 30 Nov 2011 10:05:21 PM Chris Samuel wrote:
> Currently there are 3 different capitalisations of btrfs: used in
> printk()'s, BTRFS: (3 occurences), Btrfs: (1 occurence) and btrfs:
> (77 occurences).
Unfortunately both this and the "[PATCH] Prefix mount messages with
btrfs: for clarity"
Currently when mounting a btrfs filesystem a user searching dmesg
has no obvious string to search for as currently we report something
cryptic like:
[ 5775.216078] device label DR devid 1 transid 15757 /dev/sdh1
It would be much nicer if there was some mention of btrfs to find
(as other filesyste
Currently there are 3 different capitalisations of btrfs: used in
printk()'s, BTRFS: (3 occurences), Btrfs: (1 occurence) and btrfs:
(77 occurences).
It's best to have them all the same for consistency, so we canonicalise
the two minority cases to btrfs:.
Signed-off-by: Chris Samuel
---
fs/btrf
On 29.11.2011 22:47, Chris Mason wrote:
> On Tue, Nov 29, 2011 at 09:40:56PM +0100, Arne Jansen wrote:
>> Write bios are submitted from the submit_worker. The worker pumps down
>> bios into the block layer until it signals a congestion. At least this
>> is the theory. In pratice submit_bio just blo
Any update on the state of btrfschk?
Thanks, Clemens
2011/10/31 David Summers :
> On 05/10/11 07:16, Chris Mason wrote:
>>
>>
>> So over the next two weeks I'm juggling the merge window and the fsck
>> release. My goal is to demo fsck at linuxcon europe. Thanks again for
>> all of your patience
Am 28.11.2011 10:29, schrieb Chris Samuel:
Hi Tobias,
On Mon, 28 Nov 2011, 19:16:25 EST, Tobias wrote:
The problem occurs on the stock ubuntu kernel 2.6.38-8, 3.0.0-12,
3.0.0-13 and on my self-compiled 3.1.2.
There's a lot of work gone into btrfs in 3.2,
it would be interesting to know (spea
29 matches
Mail list logo
