Excerpts from Helmut Hullen's message of 2011-01-25 09:37:00 -0500:
> crashes with the "dmesg" lines
>
> - dmesg ---
>
> bio too big device sdc (256 > 240)
> bio too big device sdc (256 > 240)
> bio too big device sdc (256 > 240)
> bio too big device sdc (256 >
any chance of getting a little more informative output?
I started the command at about 2250 Eastern and now at 0117 Eastern the command
is still running and all of the attached output happened in the first few
minutes (under 5).
btrfsck /dev/sde
trying potential super #0 at bytenr 65536
super #0
Chris Mason wrote:
> Excerpts from Li Zefan's message of 2011-01-25 20:53:00 -0500:
>> (WARNING: this patch is not completed or well-tested)
>>
>> We used to allocate inode number by searching through inode items, but
>> it made the allocation slower and slower as more and more files created.
>>
>
Hello Shawn,
it's now performing a sequential read of the volume, which will probably
take significantly more time for you than for me (where I was dealing
with an image of a 16GB SD card, stored on a recent mechanical SATA
disk).
I'm a bit confused by what happens while reading the "potential su
On 26/01/11 01:37, Helmut Hullen wrote:
> bio too big device sdc (256 > 240)
> bio too big device sdc (256 > 240)
> bio too big device sdc (256 > 240)
> bio too big device sdc (256 > 240)
Oh dear, those are errors from the block layer, looks like
btrfs is doing something wrong there.. :-(
>
Hi,
attached is the answer from Jari Ruusu, (one of?!) the main developer of
loop-aes. It
seems that checking if a loop device is mounted following the link isn't the
best
idea :)
I'll have time to look deeper into his example about the 14.02. I'll then try
to fix
that issue in mkfs.btrfs. If
On Wed, Jan 26, 2011 at 8:30 PM, Chris Mason wrote:
> My answer hasn't really changed ;) Replacing file data is a common
> operation, but it is still surprisingly complex. Again, the truncate is
> O(size of the file) and it is actually impossible to do this atomically
> in most filesystems.
Unf
Excerpts from Li Zefan's message of 2011-01-25 20:53:00 -0500:
> (WARNING: this patch is not completed or well-tested)
>
> We used to allocate inode number by searching through inode items, but
> it made the allocation slower and slower as more and more files created.
>
> The current code just r
Excerpts from Olaf van der Spek's message of 2011-01-26 13:30:08 -0500:
> On Sat, Jan 8, 2011 at 3:40 PM, Olaf van der Spek
> wrote:
> > On Fri, Jan 7, 2011 at 8:29 PM, Chris Mason wrote:
> >> The exact amount of tracking is going to vary. The reason why is that
> >> actually doing the truncate
heavy writes as well
Jan 5 16:56:46 linuscs101 kernel: [ 3666.496742] [ cut here
]
Jan 5 16:56:46 linuscs101 kernel: [ 3666.496754] WARNING: at
fs/btrfs/inode.c:2143 btrfs_orphan_commit_root+0xb0/0xc0()
Jan 5 16:56:46 linuscs101 kernel: [ 3666.496756] Hardware name
Hi,
On Wed, 2011-01-26 at 10:59 -0700, Jim Schutt wrote:
> Hi,
>
> I got this kernel BUG on a server running multiple Ceph
> cosd instances, during a heavy write load generated by
> multiple Ceph clients.
>
> The server was running the current ceph unstable kernel
> (a3f5274e535 in
> git://git
On Sat, Jan 8, 2011 at 3:40 PM, Olaf van der Spek wrote:
> On Fri, Jan 7, 2011 at 8:29 PM, Chris Mason wrote:
>> The exact amount of tracking is going to vary. The reason why is that
>> actually doing the truncate is an O(size of the file) operation and so
>> you can't just flip a switch when th
On 01/26/2011 02:53 AM, Li Zefan wrote:
> Here comes the compatability issue. It's fine to mount old btrfs, because
> we'll just use the original way to find free ino. But we can't mount new btrfs
> in older kernels, because the OFFSET makes highest objectid overflow when it
> is cast to unsigned l
Hello.
So I had the filesystem that became broken. on 2.6.37 with for-linus
unstable, when accessing some directories, it was hanging hard.
I created the metadata image and can put it somewhere if you want to
use it for something.
Thanks.
--
This message represents the official view of the voic
Hi,
I got this kernel BUG on a server running multiple Ceph
cosd instances, during a heavy write load generated by
multiple Ceph clients.
The server was running the current ceph unstable kernel
(a3f5274e535 in
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git).
Please let me k
Hallo, Yan,,
Du meintest am 26.01.11:
> Mark the cloned backref_node as checked in clone_backref_node()
> Signed-off-by: Yan, Zheng
> -+-
> diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
> index 045c9c2..bef9c22 100644
> -+- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@
On Miércoles, 26 de Enero de 2011 11:13:20 Erik Logtenberg escribió:
> Diego, pls don't read anything negative in my comments, I enjoy and
> respect your work very much! If you could find time to add those latest
> changes to the wiki, it would be greatly appreciated.
Thanks for your suggestion, I
Mark the cloned backref_node as checked in clone_backref_node()
Signed-off-by: Yan, Zheng
---
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 045c9c2..bef9c22 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1157,6 +1157,7 @@ static int clone_backref_node(struct
On 01/21/2011 03:32 PM, Diego Calleja wrote:
> On Viernes, 21 de Enero de 2011 10:54:00 Helmut Hullen escribió:
>
>> And I never have seen somethin like "Changelog" - that would be fine
>> too.
>
> Check the wiki, I keep that updated:
> https://btrfs.wiki.kernel.org/index.php/Main_Page#News
> Yesterday I reported a similar problem in this mailing list, in the
> thread "version".
>
> Running kernel 2.6.37 didn't show this error, but running kernel 2.6.38-
> rc2 ended with errors.
>
> Viele Gruesse!
> Helmut
Ah, indeed, just like you I use 2.6.38-rc2. Or to be more precise:
2.6.3
>> [104178.827624] entry offset 8891924480, bytes 4096, bitmap yes
>> [104178.827626] block group has cluster?: no
>> [104178.827628] 0 blocks of free space at or bigger than bytes is
>> [104178.827631] block group 17213423616 has 5368709120 bytes, 5368709120
>> used 0 pinned 0 reserved
>> [104178
Hallo, Hugo,
Du meintest am 26.01.11:
>> It took me a couple of days, because I needed to patch my kernel
>> first and then issue a rebalance, which ran for more than two days.
>> Nevertheless, the rebalance succeeded without any "kernel
>> BUG"-messages, so apparently your patch works!
[...]
>
On Wed, Jan 26, 2011 at 10:04:02AM +0100, Erik Logtenberg wrote:
> Hi,
>
> It took me a couple of days, because I needed to patch my kernel first
> and then issue a rebalance, which ran for more than two days.
> Nevertheless, the rebalance succeeded without any "kernel BUG"-messages,
> so apparent
Hi,
It took me a couple of days, because I needed to patch my kernel first
and then issue a rebalance, which ran for more than two days.
Nevertheless, the rebalance succeeded without any "kernel BUG"-messages,
so apparently your patch works!
I noticed that at first, the messages were like this:
24 matches
Mail list logo
