btrfs_create_tree() will unconditionally generate UUID for any root.
So for quota tree and data reloc tree created by kernel, they will have
unique UUIDs.
However UUID in root item is only referred by UUID tree, which only
records UUID for fs trees.
This makes unique UUIDs for quota/data reloc tre
For case like tree reloc trees and subvolume trees, their key offset is
the tree id.
For case like tree treloc tree for data reloc tree,
The key will be outputted as:
(TREE_RELOC ROOT_ITEM 18446744073709551607)
The minus number is long and even guys with real engineer brains can't
easily get the
Tree reloc tree is a special tree with very short life spawn.
It acts as a special snapshot for any tree, with related nodes/leaves or
EXTENT_DATA modified to point to new position.
Considering the short life spawn and its specialness, it should be quite
reasonable to keep them as both corner case
On 2017年10月31日 13:40, Misono, Tomohiro wrote:
> Currently c/o/s/r time of ROOT_ITEM is not printed in print_root_item().
> Fix this and print them if the values are not zero. print_timespec()
> is moved forward to reuse.
>
> Signed-off-by: Tomohiro Misono
Reviewed-by: Qu Wenruo
Thanks,
Qu
>
On 31/10/17 00:37, Chris Murphy wrote:
But off hand it sounds like hardware was sabotaging the expected write
ordering. How to test a given hardware setup for that, I think, is
really overdue. It affects literally every file system, and Linux
storage technology.
It kinda sounds like to me someth
On 2017年10月31日 13:39, Misono, Tomohiro wrote:
> UUID of ROOT_ITEM is empty if it is not subvolume (and not created by
> kernel). So, just skip it if it is empty just like parent/received UUID.
>
> Signed-off-by: Tomohiro Misono
Reviewed-by: Qu Wenruo
Thanks,
Qu
> ---
> print-tree.c | 6
On 2017/10/31 13:03, Qu Wenruo wrote:
> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
> key objectid and key offset are just half of the UUID.
>
> However we just print the key as %llu, which is converted from little
> endian, not byte order for UUID, nor the tradition
Currently c/o/s/r time of ROOT_ITEM is not printed in print_root_item().
Fix this and print them if the values are not zero. print_timespec()
is moved forward to reuse.
Signed-off-by: Tomohiro Misono
---
ctree.h | 32
print-tree.c | 52 ++
UUID of ROOT_ITEM is empty if it is not subvolume (and not created by
kernel). So, just skip it if it is empty just like parent/received UUID.
Signed-off-by: Tomohiro Misono
---
print-tree.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/print-tree.c b/print-tree.c
ind
For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
key objectid and key offset are just half of the UUID.
However we just print the key as %llu, which is converted from little
endian, not byte order for UUID, nor the traditional 36 bytes human
readable uuid format.
Although
On 2017年10月31日 10:55, Misono, Tomohiro wrote:
> On 2017/10/30 17:32, Qu Wenruo wrote:
>>
>>
>> On 2017年10月30日 16:14, Misono, Tomohiro wrote:
>>> Currently, the top-level subvolume lacks the UUID. As a result, both
>>> non-snapshot subvolume and snapshot of top-level subvolume do not have
>>> Pare
On 2017/10/30 17:39, Qu Wenruo wrote:
>
>
> On 2017年10月30日 16:10, Misono, Tomohiro wrote:
>> In the print_inode_item(), the argument order of sequence and flags are
>> reversed:
>>
>> printf("... sequence %llu flags 0x%llx(%s)\n",
>> ...
>> (unsigned lo
On 2017/10/30 17:32, Qu Wenruo wrote:
>
>
> On 2017年10月30日 16:14, Misono, Tomohiro wrote:
>> Currently, the top-level subvolume lacks the UUID. As a result, both
>> non-snapshot subvolume and snapshot of top-level subvolume do not have
>> Parent UUID and cannot be distinguisued. Therefore "fi sho
Duncan posted on Mon, 30 Oct 2017 04:09:58 + as excerpted:
> Zak Kohler posted on Sun, 29 Oct 2017 21:57:00 -0400 as excerpted:
>
>> So I ran memtest86+ 5.01 for >4 days:
>> Pass: 39 Errors: 0
>
> Be aware that memtest86+ will detect some types of errors but not
> others.
>
> In particular,
On 10/30/2017 10:39 PM, David Sterba wrote:
On Fri, Oct 20, 2017 at 10:07:15PM +0800, Anand Jain wrote:
We aren't setting the FMODE_WRITE when initializing btrfs_device
structure and when calling blkdev_put, however we are setting it
only when calling blkdev_get_by_path().
But this still doe
Dave posted on Sun, 29 Oct 2017 23:31:57 -0400 as excerpted:
> It's all part of the process of gaining critical experience with BTRFS.
> Whether or not BTRFS is ready for production use is (it seems to me)
> mostly a question of how knowledgeable and experienced are the people
> administering it.
On Mon, Oct 30, 2017 at 5:21 PM, Qu Wenruo wrote:
>
>
> On 2017年10月31日 06:32, Justin Maggard wrote:
>> This test case does some concurrent send/receives with qgroups enabled.
>> Currently (4.14-rc7) this usually results in btrfs check errors, and
>> often also results in a WARN_ON in record_root_i
On 2017年10月31日 06:32, Justin Maggard wrote:
> This test case does some concurrent send/receives with qgroups enabled.
> Currently (4.14-rc7) this usually results in btrfs check errors, and
> often also results in a WARN_ON in record_root_in_trans().
>
> Bisecting points to 6426c7ad697d (btrfs: q
On 2017年10月31日 01:14, Liu Bo wrote:
> First and foremost, here are the problems we have right now,
>
> a) %thread_pool is configurable via mount option, however for those
>'workers' who really needs concurrency, there are at most
>"min(num_cpus+2, 8)" threads running to process works, an
On 2017年10月31日 06:29, Justin Maggard wrote:
> Commit c6887cd11149 (Btrfs: don't do nocow check unless we have to)
> changed the behavior of __btrfs_buffered_write() so that it first tries
> to get a data space reservation, and then skips the relatively expensive
> nocow check if the reservation s
This test case writes into pre-allocated space, then tries to fallocate
some more within the defined quota limit. Currently (4.14-rc7) this fails
with EDQUOT due to quota reservation leakage when writing into pre-
allocated space.
A possible fix has been sent to the ML as "btrfs: Fix quota reserva
This test case does some concurrent send/receives with qgroups enabled.
Currently (4.14-rc7) this usually results in btrfs check errors, and
often also results in a WARN_ON in record_root_in_trans().
Bisecting points to 6426c7ad697d (btrfs: qgroup: Fix qgroup accounting
when creating snapshot) as
Commit c6887cd11149 (Btrfs: don't do nocow check unless we have to)
changed the behavior of __btrfs_buffered_write() so that it first tries
to get a data space reservation, and then skips the relatively expensive
nocow check if the reservation succeeded.
If we have quotas enabled, the data space r
On Mon, Oct 30, 2017 at 4:31 AM, Dave wrote:
> This is a very helpful thread. I want to share an interesting related story.
>
> We have a machine with 4 btrfs volumes and 4 Snapper configs. I
> recently discovered that Snapper timeline cleanup been turned off for
> 3 of those volumes. In the Snapp
On Mon, Oct 30, 2017 at 2:57 AM, Zak Kohler wrote:
> $ sudo btrfs scrub start --offline --progress /dev/disk/by-id/WD-XX1
> Scrub result:
> Tree bytes scrubbed: 5234425856
> Tree extents scrubbed: 638968
> Data bytes scrubbed: 4353723670528
> Data extents scrubbed: 374300
> Data bytes without csu
On Mon, Oct 16, 2017 at 11:53:08AM +0300, Nikolay Borisov wrote:
>
>
> On 13.10.2017 23:51, Liu Bo wrote:
> > On Wed, Oct 11, 2017 at 10:38:50AM +0300, Nikolay Borisov wrote:
> >>
> >>
> >> On 10.10.2017 20:53, Liu Bo wrote:
> >>> We've avoided data losing raid profile when doing balance, but it
On Mon, Oct 30, 2017 at 11:14:38AM -0600, Liu Bo wrote:
> If a file's DIR_ITEM key is invalid (due to memory errors) and gets
> written to disk, a future lookup_path can end up with kernel panic due
> to BUG_ON().
>
> This gets rid of the BUG_ON(), meanwhile output the corrupted key and
> return E
First and foremost, here are the problems we have right now,
a) %thread_pool is configurable via mount option, however for those
'workers' who really needs concurrency, there are at most
"min(num_cpus+2, 8)" threads running to process works, and the
value can't be tuned after mount becaus
If a file's DIR_ITEM key is invalid (due to memory errors) and gets
written to disk, a future lookup_path can end up with kernel panic due
to BUG_ON().
This gets rid of the BUG_ON(), meanwhile output the corrupted key and
return ENOENT if it's invalid.
Signed-off-by: Liu Bo
---
The diff doesn't
"submit_workers" is a workqueue that serves to collect and dispatch IOs
on each device in btrfs, thus the work that is queued on it is
per-device, which means at most there're as many works as the number
of devices owned by a btrfs.
Now we've set threshhold (=64) for "submit_workers" and the
'max_
On Wed, Oct 11, 2017 at 11:02:49AM -0600, Liu Bo wrote:
> On Wed, Oct 11, 2017 at 03:41:23PM +0800, Anand Jain wrote:
> >
> >
> > On 10/11/2017 02:11 PM, Anand Jain wrote:
> > >
> > >
> > > On 10/11/2017 05:51 AM, Liu Bo wrote:
> > > > It was introduced because btrfs used to do blkdev_put in a
On Mon, Oct 23, 2017 at 07:43:02PM +0800, Qu Wenruo wrote:
>
>
> On 2017年10月23日 18:51, Nikolay Borisov wrote:
> > Currently btrfs_async_run_delayed_root's implementation uses 3 goto labels
> > to
> > mimic the functionality of a simple do {} while loop. Refactor the function
> > to use a do {} w
On Mon, Oct 23, 2017 at 10:29:27AM -0600, Edmund Nadolski wrote:
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -1765,20 +1765,24 @@ static int btrfs_rm_dev_item(struct btrfs_fs_info
> > *fs_info,
> > key.offset = device->devid;
> >
> > ret = btrfs_search_slot(trans, ro
On Wed, Oct 25, 2017 at 03:59:08PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> This implements support the zero range operation of fallocate. For now
> at least it's as simple as possible while reusing most of the existing
> fallocate and hole punching infrastructure.
>
> Signed-
On Fri, Oct 20, 2017 at 10:07:15PM +0800, Anand Jain wrote:
> We aren't setting the FMODE_WRITE when initializing btrfs_device
> structure and when calling blkdev_put, however we are setting it
> only when calling blkdev_get_by_path().
But this still does not say why this is a problem worth fixing
Lakshmipathi.G posted on Mon, Oct 30, 2017 at 12:07 AM as excerpted:
> Can you share these steps as simple bash script? Currently I'm running
> few tests, I can check your script and share the results.
sure, but it is pretty trivial:
device1=/dev/disk/by-id/XX1
device2=/dev/disk/by-id/XX2
device
On 10/30/2017 09:01 AM, Nikolay Borisov wrote:
>
>
> On 30.10.2017 15:55, David Sterba wrote:
>> On Mon, Oct 30, 2017 at 03:21:51PM +0200, Nikolay Borisov wrote:
>>>
>>>
>>> On 27.10.2017 07:17, Liu Bo wrote:
On Tue, Oct 24, 2017 at 05:47:11AM -0500, Goldwyn Rodrigues wrote:
>
> EX
On 30.10.2017 15:55, David Sterba wrote:
> On Mon, Oct 30, 2017 at 03:21:51PM +0200, Nikolay Borisov wrote:
>>
>>
>> On 27.10.2017 07:17, Liu Bo wrote:
>>> On Tue, Oct 24, 2017 at 05:47:11AM -0500, Goldwyn Rodrigues wrote:
EXTENT_PAGE_MAPPED gets set in set_page_extent_mapped(), but I d
On Mon, Oct 30, 2017 at 03:21:51PM +0200, Nikolay Borisov wrote:
>
>
> On 27.10.2017 07:17, Liu Bo wrote:
> > On Tue, Oct 24, 2017 at 05:47:11AM -0500, Goldwyn Rodrigues wrote:
> >>
> >> EXTENT_PAGE_MAPPED gets set in set_page_extent_mapped(), but I don't see
> >> it being cross checked anytime.
On Mon, Oct 23, 2017 at 11:18:16PM -0600, Liu Bo wrote:
> Compression code path has only flaged bios with REQ_OP_WRITE no matter
> where the bios come from, but it could be a sync write if fsync starts
> this writeback or a normal writeback write if wb kthread starts a
> periodic writeback.
>
> It
On Tue, Oct 24, 2017 at 11:50:39AM +0300, Nikolay Borisov wrote:
> The following callpath is always invoked with mirror_num set to 0, so let's
> remove it as an argument and directly pass 0 to __do_redpage. No functional
> change
>
> extent_readpages
> __extent_readpages
> __do_contiguous_r
On 27.10.2017 07:17, Liu Bo wrote:
> On Tue, Oct 24, 2017 at 05:47:11AM -0500, Goldwyn Rodrigues wrote:
>>
>> EXTENT_PAGE_MAPPED gets set in set_page_extent_mapped(), but I don't see
>> it being cross checked anytime. What is the purpose of setting it?
>
> Please check commit d1310b2e0cd98eb1348
On Fri, 2017-05-12 at 12:21 -0400, J. Bruce Fields wrote:
> On Fri, May 12, 2017 at 08:22:23AM +1000, NeilBrown wrote:
> > On Thu, May 11 2017, J. Bruce Fields wrote:
> > > +static inline u64 nfsd4_change_attribute(struct inode *inode)
> > > +{
> > > + u64 chattr;
> > > +
> > > + chattr = inode->i_
On Thu, Oct 19, 2017 at 09:49:27AM +0800, Gu Jinxiang wrote:
> From: Gu JinXiang
>
> Fix bug of commit 74d46992e0d9
> ("block: replace bi_bdev with a gendisk pointer and partitions index").
>
> In this modify, use bio_dev(bio) to find dev state in function
> __btrfsic_submit_bio. But when dev_st
On Fri, Oct 20, 2017 at 06:10:58PM +0300, Nikolay Borisov wrote:
> As per atomic_t.txt documentation :
> - RMW operations that have a return value are fully ordered;
>
> atomic_xchg is one such operation so it already includes everything it needs
> w.r.t memory ordering and add a comment ot be mo
On Sat, Oct 21, 2017 at 01:45:33AM +0800, Anand Jain wrote:
> btrfs_end_bio() is using btrfs_dev_stat_inc() and then
> btrfs_dev_stat_print_on_error() separately instead use
> btrfs_dev_stat_inc_and_print() directly.
>
> As of now there isn't any bio in btrfs which is - a non-empty write and
> als
On Sun, 29 Oct 2017, at 06:02 PM, Qu Wenruo wrote:
> If so, mount it, do minimal write like creating an empty file, to update
> both superblock copies, and then try fix-device-size.
Tried that, and it didn't work. Made a recording:
https://youtu.be/SFd3QscNT6w
--
To unsubscribe from this list: sen
On 2017年10月30日 16:10, Misono, Tomohiro wrote:
> In the print_inode_item(), the argument order of sequence and flags are
> reversed:
>
> printf("... sequence %llu flags 0x%llx(%s)\n",
> ...
> (unsigned long long)btrfs_inode_flags(eb,ii),
>
On 2017年10月30日 16:14, Misono, Tomohiro wrote:
> Currently, the top-level subvolume lacks the UUID. As a result, both
> non-snapshot subvolume and snapshot of top-level subvolume do not have
> Parent UUID and cannot be distinguisued. Therefore "fi show" of
> top-level lists all the subvolumes whic
On 2017年10月30日 16:10, Misono, Tomohiro wrote:
> In the print_inode_item(), the argument order of sequence and flags are
> reversed:
>
> printf("... sequence %llu flags 0x%llx(%s)\n",
> ...
> (unsigned long long)btrfs_inode_flags(eb,ii),
>
Allow "fi show -u" for uuid of top-level subvolume too for consistency.
Signed-off-by: Tomohiro Misono
---
btrfs-list.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/btrfs-list.c b/btrfs-list.c
index b6d7658..91fdab8 100644
--- a/btrfs-list.c
+++ b/btrfs-list.c
Currently, the top-level subvolume lacks the UUID. As a result, both
non-snapshot subvolume and snapshot of top-level subvolume do not have
Parent UUID and cannot be distinguisued. Therefore "fi show" of
top-level lists all the subvolumes which lacks the UUID in
"Snapshot(s)". Also, it lacks the ot
In the print_inode_item(), the argument order of sequence and flags are
reversed:
printf("... sequence %llu flags 0x%llx(%s)\n",
...
(unsigned long long)btrfs_inode_flags(eb,ii),
(unsigned long long)btrfs_inode_sequence(eb, ii),
53 matches
Mail list logo
