On Mon, Jun 13, 2011 at 09:10:39PM +0200, Jan Schmidt wrote:
> This removes a FIXME comment and introduces the first part of nodatasum
> fixup: It gets the corresponding inode for a logical address and triggers a
> regular readpage for the corrupted sector.
>
> Once we have on-the-fly error correc
On Mon, Jun 13, 2011 at 09:10:36PM +0200, Jan Schmidt wrote:
> While scrubbing, we may encounter various errors. Previously, a logical
> address was printed to the log only. Now, all paths belonging to that
> address are resolved and printed separately. That should work for hardlinks
> as well as r
On Mon, Jun 13, 2011 at 09:10:35PM +0200, Jan Schmidt wrote:
> In normal operation, scrub is reading data sequentially in large portions.
> In case of an i/o error, we try to find the corrupted area(s) by issuing
> page sized read requests. With this commit we increment the
> unverified_errors coun
On Mon, Jun 13, 2011 at 09:10:34PM +0200, Jan Schmidt wrote:
> These helper functions iterate back references and call a function for each
> backref. There is also a function to resolve an inode to a path in the
> file system.
>
> Signed-off-by: Jan Schmidt
> ---
> fs/btrfs/Makefile |3 +-
>
Hi Helmut
On 06/16/2011 05:09 PM, Helmut Hullen wrote:
Hallo, Josef,
Du meintest am 16.06.11:
Who the hell doesn't use udev?
Me - p.e.
"udev" may be interesting for desktop users, for multimedia
computers. It's not necessary for a simple server, for a machine
where the administrator wants
On 06/16/2011 01:17 PM, Mitch Harder wrote:
> On Thu, Jun 16, 2011 at 9:52 AM, Josef Bacik wrote:
>> On 06/16/2011 10:36 AM, Mitch Harder wrote:
>>> 2011/6/15 Josef Bacik :
On 06/15/2011 06:47 AM, Miao Xie wrote:
> The following deadlock may happen when doing reservation for metadata:
>>>
On Thu, Jun 16, 2011 at 9:52 AM, Josef Bacik wrote:
> On 06/16/2011 10:36 AM, Mitch Harder wrote:
>> 2011/6/15 Josef Bacik :
>>> On 06/15/2011 06:47 AM, Miao Xie wrote:
The following deadlock may happen when doing reservation for metadata:
Task0 Flush thread
Hallo, Josef,
Du meintest am 16.06.11:
>>> Who the hell doesn't use udev?
>> Me - p.e.
>> "udev" may be interesting for desktop users, for multimedia
>> computers. It's not necessary for a simple server, for a machine
>> where the administrator wants to rule instead of "udev".
> You don't need
On 06/16/2011 10:45 AM, Helmut Hullen wrote:
> Hallo, Josef,
>
> Du meintest am 16.06.11:
>
>>> Thank you - it's nice for all who don't use udev.
>
>> Who the hell doesn't use udev?
>
> Me - p.e.
> "udev" may be interesting for desktop users, for multimedia computers.
> It's not necessary for
Hallo, Josef,
Du meintest am 16.06.11:
>> Thank you - it's nice for all who don't use udev.
> Who the hell doesn't use udev?
Me - p.e.
"udev" may be interesting for desktop users, for multimedia computers.
It's not necessary for a simple server, for a machine where the
administrator wants t
On 06/16/2011 10:36 AM, Mitch Harder wrote:
> 2011/6/15 Josef Bacik :
>> On 06/15/2011 06:47 AM, Miao Xie wrote:
>>> The following deadlock may happen when doing reservation for metadata:
>>>
>>> Task0 Flush threadTask1
>>> start_transaction()
>>> shrink_delall
2011/6/15 Josef Bacik :
> On 06/15/2011 06:47 AM, Miao Xie wrote:
>> The following deadlock may happen when doing reservation for metadata:
>>
>> Task0 Flush thread Task1
>> start_transaction()
>> shrink_delalloc()
>> writeback_inodes_sb_nr()
>> wait f
On 06/15/2011 04:35 PM, Helmut Hullen wrote:
> Hallo, Goffredo,
>
> Du meintest am 15.06.11:
>
>> thanks to the last Hugo's email, I restart to work on the patch which
>> avoid to scan cdrom and floppy during a "btrfs filesystem show" and a
>> "btrfs device scan". Comparing to my previous patch I
> Defrag works on individual files, and tries to find a contiguous
> sequence of bytes to write the file's data to. In the process, the
> current implementation will break any CoW duplication -- either within
> single files (copies with cp --reflink=always) or files copied via
> snapshotting.
W
As btrfs uses delay allocation mechanism and data=order mode, there can be
a period window, during which we sub delalloc_bytes and add_inode_bytes,
and we may get a value of '0' referred to inode's blocks via 'ls -lis'.
ino:291 blocks:198656 i_blocks:0 i_bytes:0 delalloc_bytes:101711872
ino:291 bl
In btrfs's in-memory inode, there is a btrfs_key which has the structure:
- key.objectid : inode id
- key.type: BTRFS_INODE_ITEM_KEY
- key.offset: 0 or -1ULL
however, we only use key.objectid to search, to check or something else,
and to reduce in-memory inode size I just keep what is valuable.
S
In btrfs's in-memory inode, there is a btrfs_key which has the structure:
- key.objectid : inode id
- key.type: BTRFS_INODE_ITEM_KEY
- key.offset: 0 or -1ULL
however, we only use key.objectid to search, to check or something else,
and to reduce in-memory inode size I just keep what is valuable.
S
As btrfs uses delay allocation mechanism and data=order mode, there can be
a period window, during which we sub delalloc_bytes and add_inode_bytes,
and we may get a value of '0' referred to inode's blocks via 'ls -lis'.
ino:291 blocks:198656 i_blocks:0 i_bytes:0 delalloc_bytes:101711872
ino:291 bl
Removes code no longer used. The sysfs file itself is kept, because the
btrfs developers expressed interest in putting new entries to sysfs.
Signed-off-by: Maarten Lankhorst
---
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 378b5b4..81f4083 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/c
19 matches
Mail list logo
