Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now
if i run some file operations like find, i get these messages.
kernel is 2.6.38.5-1 on arch linux
May 5 14:15:12 mail kernel: [13559.089713] parent transid verify failed
on 3062073683968 wanted 5181 found 5188
May 5
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 07:19:52 -0400:
Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now
if i run some file operations like find, i get these messages.
kernel is 2.6.38.5-1 on arch linux
Are all of the messages for this one block?
On 5/5/2011 2:42 μμ, Chris Mason wrote:
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 07:19:52 -0400:
Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now
if i run some file operations like find, i get these messages.
kernel is 2.6.38.5-1 on arch linux
Are
Hi,
another round of cleanups, removing unused code. No functional chanes.
The diffstat is quite big, please have a look if you feel that some code
is unused by accident.
thanks,
david
David Sterba (3):
btrfs: remove unused function prototypes
btrfs: remove all unused functions
btrfs:
Remove static and global declarations and/or definitions. Reduces size
of btrfs.ko by ~3.4kB.
textdata bss dec hex filename
4020817464 200 409745 64091 btrfs.ko.base
3986207144 200 405964 631cc btrfs.ko.remove-all
Signed-off-by: David Sterba
function prototypes without a body
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.h | 12
fs/btrfs/delayed-ref.h |5 -
fs/btrfs/disk-io.h | 11 ---
fs/btrfs/extent_io.h |9 -
fs/btrfs/transaction.h |3 ---
When creating a mixed fs with mkfs, an extra metadata chunk got allocated.
This is because btrfs_reserve_extent calls do_chunk_alloc for METADATA,
which in turn wasn't able to find the proper space_info, as __find_space_info
did a hard compare of the flags. It is now sufficient for the space_info
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 07:45:08 -0400:
On 5/5/2011 2:42 μμ, Chris Mason wrote:
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 07:19:52 -0400:
Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now
if i run some file
On Fri, 08 Apr 2011 16:44:37 +0800
liubo liubo2...@cn.fujitsu.com wrote:
When a btrfs disk is created by mixed data metadata option, it will have no
pure data or pure metadata space info.
In btrfs's for-linus branch, commit 78b1ea13838039cd88afdd62519b40b344d6c920
(Btrfs: fix OOPS of
On Wednesday 4 May, 2011 02:51:54 Sander wrote:
Put an exit on top of /etc/kernel/postrm.d/zz-update-grub and try again.
Install grub-pc 1.99~rc1-13 from Sid.
First I put an exit right after #! /bin/sh and it failed. Then I moved
/etc/kernel/postrm.d/zz-update-grub to / and it still
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 10:27:30 -0400:
attached you can find the whole dmesg log. I can trigger the error again
if more logs are needed
Yes, I'll send you a patch to get rid of the printk for the transid
failed message. That way we can get a clean view of
On 5/5/2011 6:06 μμ, Chris Mason wrote:
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 10:27:30 -0400:
attached you can find the whole dmesg log. I can trigger the error again
if more logs are needed
Yes, I'll send you a patch to get rid of the printk for the transid
failed
On Thu, May 05, 2011 at 02:12:03PM +0200, wh...@gmx.com wrote:
Seems like the mail didn't get trough, trying again with the logfile
compressed.
Thanks,
On Wednesday 04 May 2011 20:21:54 you wrote:
[...]
Argh sorry I was looking at the wrong part of that warning. Can you run
with
Anyone have a suggestion?
Also on another machine set up similarly, I now cannot mkdir. It says 'no
space left on device'. df says:
# df /dev/sdb
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb 3907029168 2658010524 1246486516 69% /home
sdb and sdc
On Wed, May 04, 2011 at 08:51:39AM -0600, Andreas Dilger wrote:
I was aware of REQ_META, but I didn't know there was any benefit to
using it. I think it would be easy to set REQ_META on all ext4 metadata
if there was a reason to do so.
The CFQ ioscheduler pays attention to it (prioritising
On 05/05/2011 01:54 PM, wh...@gmx.com wrote:
On Thursday 05 May 2011 19:53:52 Josef Bacik wrote:
[...]
Hmm I didn't see what I needed, can you do it again and try to get kernel
messages to go to /var/log/messages so you don't have to worry about the
log buffer? The other option is to setup
Il 05/05/2011 21:01, Josef Bacik ha scritto:
On 05/05/2011 02:54 PM, Marco Stornelli wrote:
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset= i_size_read(inode)) {
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
Here maybe it's possible to
On Thu, May 5, 2011 at 12:09 PM, cac...@quantum-sci.com wrote:
Anyone have a suggestion?
Also on another machine set up similarly, I now cannot mkdir. It says 'no
space left on device'. df says:
# df /dev/sdb
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset= i_size_read(inode)) {
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
I can add that
On Thu, May 5, 2011 at 8:49 AM, cac...@quantum-sci.com wrote:
On Wednesday 4 May, 2011 02:51:54 Sander wrote:
Put an exit on top of /etc/kernel/postrm.d/zz-update-grub and try again.
Install grub-pc 1.99~rc1-13 from Sid.
First I put an exit right after #! /bin/sh and it failed. Then I
On 05/05/2011 03:19 PM, Marco Stornelli wrote:
Il 04/05/2011 19:58, Josef Bacik ha scritto:
+ if (offset= i_size_read(inode)) {
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+ }
+ offset = i_size_read(inode);
+ break;
I can add that generic_file_llseek_unlocked means *unlocked* so you
I was afraid of this finger-pointing.
Of course no one at Debian is going to know how to fix BTRFS jamming the
package management system. That's ridiculous.
It's starting to look like BTRFS is just busted in Debian, and I'll have to
reinstall everything over a different filesystem. I hate
Excerpts from CACook's message of 2011-05-05 15:50:02 -0400:
I was afraid of this finger-pointing.
We're not finger pointing, but we also don't maintain the script that is
failing. I'm happy to patch up bugs in the FS (or point you to newer
kernels that have them fixed) but at this point we
On May 5, 2011, at 12:10, Matthew Wilcox wrote:
On Wed, May 04, 2011 at 08:51:39AM -0600, Andreas Dilger wrote:
I was aware of REQ_META, but I didn't know there was any benefit to
using it. I think it would be easy to set REQ_META on all ext4 metadata
if there was a reason to do so.
The CFQ
This just gets us ready to support the SEEK_HOLE and SEEK_DATA flags. Turns out
using fiemap in things like cp cause more problems than it solves, so lets try
and give userspace an interface that doesn't suck. So we have
-SEEK_HOLE: move the file position to the start of the next hole greater
Since Ext4 has its own lseek we need to make sure it handles
SEEK_HOLE/SEEK_DATA. For now just do the same thing that is done in the generic
case, somebody else can come along and make it do fancy things later. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
v2-v3: Nothing since this is
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 this seems to cover most of the corner
In order to handle SEEK_HOLE/SEEK_DATA we need to implement our own llseek.
Basically for the normal SEEK_*'s we will just defer to the generic helper, and
for SEEK_HOLE/SEEK_DATA we will use our fiemap helper to figure out the nearest
hole or data. Currently this helper doesn't check for
I think i made some progress. When i tried to remove the directory that
i suspect contains the problematic file, i got this on the console
rm -rf serverloft/
2011 May 5 23:32:53 mail [ 200.580195] Oops: [#1] PREEMPT SMP
2011 May 5 23:32:53 mail [ 200.580220] last sysfs file:
On Thu, May 5, 2011 at 1:50 PM, cac...@quantum-sci.com wrote:
I was afraid of this finger-pointing.
Of course no one at Debian is going to know how to fix BTRFS jamming the
package management system. That's ridiculous.
I took the liberty of asking #debian, and they've requested that you
Here is the relevant section of strace:
-
chmod(/etc/grub.d/05_debian_theme.dpkg-new, 0755) = 0
unlink(/etc/grub.d/05_debian_theme.dpkg-new) = 0
stat(/etc/localtime, {st_mode=S_IFREG|0644, st_size=2819,
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400:
I think i made some progress. When i tried to remove the directory that
i suspect contains the problematic file, i got this on the console
rm -rf serverloft/
Ok, our one bad block is in the extent allocation tree.
On Thu, May 5, 2011 at 2:32 PM, cac...@quantum-sci.com wrote:
Here is the relevant section of strace:
BTW, I fixed the 'no space left on device' on the other machine with a btrfs
balance. No one seems to know this, but even though df reports that 64% of
the disk array is used, apparently
On Thursday 5 May, 2011 13:31:17 cwillu wrote:
I took the liberty of asking #debian, and they've requested that you
file a bug in their bug tracker. They've also suggested that you
might be able to short-circuit the faulty script in their kernel
package via an exit 0, or even replace the
On 5/5/2011 11:32 μμ, Chris Mason wrote:
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400:
I think i made some progress. When i tried to remove the directory that
i suspect contains the problematic file, i got this on the console
rm -rf serverloft/
Ok, our one bad
On to, 2011-05-05 at 13:57 -0700, cac...@quantum-sci.com wrote:
On Thursday 5 May, 2011 13:31:17 cwillu wrote:
I took the liberty of asking #debian, and they've requested that you
file a bug in their bug tracker. They've also suggested that you
might be able to short-circuit the faulty
On Thu, May 5, 2011 at 2:57 PM, cac...@quantum-sci.com wrote:
On Thursday 5 May, 2011 13:31:17 cwillu wrote:
I took the liberty of asking #debian, and they've requested that you
file a bug in their bug tracker. They've also suggested that you
might be able to short-circuit the faulty script
On Thursday 5 May, 2011 13:40:25 cwillu wrote:
Could you include the information I asked for previously? (Kernel
version, output of btrfs fi df and btrfs fi show)
Kernel 2.6.37-2
# btrfs fi df /home
Data, RAID0: total=2.61TB, used=2.47TB
Data: total=8.00MB, used=8.00MB
System, RAID1:
On Thursday 5 May, 2011 13:59:23 Lars Wirzenius wrote:
dpkg --fsys-tarfile foo.deb | tar -C / -tf -
I was expecting this to extract into the local directory, although it seems to
have extracted into the final destinations. Can't be sure. grub-setup -V
gives the new version.
change -t to
On Thu, May 5, 2011 at 3:40 PM, cac...@quantum-sci.com wrote:
On Thursday 5 May, 2011 13:40:25 cwillu wrote:
Could you include the information I asked for previously? (Kernel
version, output of btrfs fi df and btrfs fi show)
Kernel 2.6.37-2
# btrfs fi df /home
Data, RAID0: total=2.61TB,
On Thu, May 5, 2011 at 3:48 PM, cac...@quantum-sci.com wrote:
On Thursday 5 May, 2011 13:59:23 Lars Wirzenius wrote:
dpkg --fsys-tarfile foo.deb | tar -C / -tf -
I was expecting this to extract into the local directory, although it seems
to have extracted into the final destinations. Can't
Hello!
I have a 1 TB ext4 drive that's quite full (~50 GB free space, though I
could free up another 100 GB or so if necessary) and two empty 0.5 TB
drives.
Is it possible to get another 1 TB drive and combine the four drives to
a btrfs raid10 setup without (if all goes well) losing my data?
On Thu, May 05, 2011 at 05:01:04PM -0400, Paul Schroeder wrote:
I have a 1 TB ext4 drive that's quite full (~50 GB free space, though I
could free up another 100 GB or so if necessary) and two empty 0.5 TB
drives.
Is it possible to get another 1 TB drive and combine the four drives to
a
On 05/03/2011 06:50 PM, cwillu wrote:
On Tue, May 3, 2011 at 7:32 PM, Geoff Rittergeoff.rit...@gmail.com wrote:
Not sure where to report bugs or even find a coherent list of them. Sorry
if this is already well known.
When attempting to use an unlocked encrypted device as either a seed
On Thursday 5 May, 2011 14:48:49 cwillu wrote:
How old was the filesystem? It might just have been lingering
problems from an older kernel, which would be cleared up entirely by
the balance you just ran.
I specifically set up the filesystem with the Live CD of the M- release of
Ubuntu, so as
On Thu, May 5, 2011 at 6:33 PM, cac...@quantum-sci.com wrote:
On Thursday 5 May, 2011 14:48:49 cwillu wrote:
How old was the filesystem? It might just have been lingering
problems from an older kernel, which would be cleared up entirely by
the balance you just ran.
I specifically set up
Excerpts from cwillu's message of 2011-05-03 21:50:53 -0400:
On Tue, May 3, 2011 at 7:32 PM, Geoff Ritter geoff.rit...@gmail.com wrote:
Not sure where to report bugs or even find a coherent list of them. Sorry
if this is already well known.
When attempting to use an unlocked encrypted
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 17:04:00 -0400:
On 5/5/2011 11:32 μμ, Chris Mason wrote:
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400:
I think i made some progress. When i tried to remove the directory that
i suspect contains the
Chris Mason wrote:
We've had trouble in the past with block dev flushing code kicking
in as devices are resized.
Might this be the problem with my root node? I wish my problem was
in only one directory. :)
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the
On 05/05/2011 10:16 PM, Arne Jansen wrote:
When creating a mixed fs with mkfs, an extra metadata chunk got allocated.
This is because btrfs_reserve_extent calls do_chunk_alloc for METADATA,
which in turn wasn't able to find the proper space_info, as __find_space_info
did a hard compare of the
The current code relogs the entire inode every time during fsync log,
and it is much better suited to small files rather than large ones.
During my performance test, the fsync performace of large files sucks,
and we can ascribe this to the tremendous amount of csum infos of the
large ones, cause
Hallo, Cacook,
Du meintest am 05.05.11:
I took all pains to be using the newest OS available to set up the
disks, so as to take advantage of WD's Advanced Format, and the
newest improvements to BTRFS. But the balance is still going after
more than an hour.
Where's the problem? Balancing 4
On 6/5/2011 2:50 πμ, Chris Mason wrote:
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 17:04:00 -0400:
On 5/5/2011 11:32 μμ, Chris Mason wrote:
Excerpts from Konstantinos Skarlatos's message of 2011-05-05 16:27:54 -0400:
I think i made some progress. When i tried to remove the
53 matches
Mail list logo
