On Wed, Nov 1, 2017 at 2:19 AM, Marat Khalili wrote:
> You seem to have two tasks: (1) same-volume snapshots (I would not call them
> backups) and (2) updating some backup volume (preferably on a different
> box). By solving them separately you can avoid some complexity...
Yes, it appears that i
On Wed, Nov 1, 2017 at 1:15 AM, Roman Mamedov wrote:
> On Wed, 1 Nov 2017 01:00:08 -0400
> Dave wrote:
>
>> To reconcile those conflicting goals, the only idea I have come up
>> with so far is to use btrfs send-receive to perform incremental
>> backups as described here:
>> https://btrfs.wiki.ker
I'm active user of backup using btrfs snapshots. Generally it works with
some caveats.
You seem to have two tasks: (1) same-volume snapshots (I would not call
them backups) and (2) updating some backup volume (preferably on a
different box). By solving them separately you can avoid some comple
On 31.10.2017 23:51, Liu Bo wrote:
> On Tue, Oct 31, 2017 at 10:23:30PM +0200, Nikolay Borisov wrote:
>>
>>
>> On 30.10.2017 19:14, 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
>>>
On Wed, 1 Nov 2017 01:00:08 -0400
Dave wrote:
> To reconcile those conflicting goals, the only idea I have come up
> with so far is to use btrfs send-receive to perform incremental
> backups as described here:
> https://btrfs.wiki.kernel.org/index.php/Incremental_Backup .
Another option is to ju
Our use case requires snapshots. btrfs snapshots are best solution we
have found for our requirements, and over the last year snapshots have
proven their value to us.
(For this discussion I am considering both the "root" volume and the
"home" volume on a typical desktop workstation. Also, all btfs
For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
key objectid and key offset is 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 t
> -Original Message-
> From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com]
> Sent: Tuesday, October 31, 2017 6:36 PM
> To: Gu, Jinxiang/顾 金香 ; linux-btrfs@vger.kernel.org
> Cc: dste...@suse.cz
> Subject: Re: [RFC PATCH 0/3] btrfs-progs: Add support for running the tools
> from
>
>
>
> On
Original reported by Wesley AC:
https://github.com/kdave/btrfs-progs/issues/70
Fix it by taking data/meta profile and minimal chunk size into
consideration.
Also introduce a test case for that.
Changelog:
v2:
Refactor test_minimum_size() to take @min_dev_size directly. Refactor
patch already
So prepare_test_dev() can be called several times in one test case, to
test different device sizes.
Signed-off-by: Qu Wenruo
---
tests/common | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/common b/tests/common
index 977bade201a6..63750dbfeffe 100644
--- a/tests/c
For later test case which needs info from stderr.
Signed-off-by: Qu Wenruo
---
tests/common | 52
1 file changed, 52 insertions(+)
diff --git a/tests/common b/tests/common
index dec090fe5849..977bade201a6 100644
--- a/tests/common
+++ b/tests
New test case to test if the minimal device size given by "mkfs.btrfs"
failure case is valid.
Signed-off-by: Qu Wenruo
---
tests/mkfs-tests/010-small-image/test.sh | 49
1 file changed, 49 insertions(+)
create mode 100755 tests/mkfs-tests/010-small-image/test.sh
Since commit c11e36a29e84 ("Btrfs-progs: Do not force mixed block group
creation unless '-M' option is specified"), mkfs no longer use mixed
block group unless specified manually.
This breaks the minimal device size calculation, which only considered
mixed block group use case.
This patch enhance
On Tue, Oct 31, 2017 at 7:06 PM, Peter Grandi
wrote:
>
> Also nothing forces you to defragment a whole filesystem, you
> can just defragment individual files or directories by using
> 'find' with it.
Thanks for that info. When defragmenting individual files on a BTRFS
filesystem with COW, I assu
On 10/28/2017 02:12 AM, Qu Wenruo wrote:
>
> On 2017年10月28日 02:17, Hans van Kranenburg wrote:
>> Hi,
>>
>> This is a followup to my previous threads named "About free space
>> fragmentation, metadata write amplification and (no)ssd" [0] and
>> "Experiences with metadata balance/convert" [1], explo
> I'm following up on all the suggestions regarding Firefox performance
> on BTRFS. [ ... ]
I haven't read that yet, so maybe I am missing something, but I
use Firefox with Btrfs all the time and I haven't got issues.
[ ... ]
> 1. BTRFS snapshots have proven to be too useful (and too important to
On Tue, Oct 31, 2017 at 10:23:30PM +0200, Nikolay Borisov wrote:
>
>
> On 30.10.2017 19:14, 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 t
I'm following up on all the suggestions regarding Firefox performance
on BTRFS. I have time to make these changes now, but I am having
trouble figuring out what to do. The constraints are:
1. BTRFS snapshots have proven to be too useful (and too important to
our overall IT approach) to forego.
2.
On 30.10.2017 19:14, 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 ENOENT if it's inval
Thank you very much for such an informative response!
On Tue, 2017-10-31 at 13:45 -0400, Austin S. Hemmelgarn wrote:
> On 2017-10-31 12:23, ST wrote:
> > Hello,
> >
> > I've recently learned about btrfs and consider to utilize for my needs.
> > I have several questions in this regard:
> >
> > I
On 2017-10-31 15:54, Lentes, Bernd wrote:
- On Oct 31, 2017, at 6:00 PM, Austin S. Hemmelgarn ahferro...@gmail.com
wrote:
Assuming you're careful about how you install it (that is, put it in a
custom prefix that isn't in $PATH), you could always build a local
version of Python. Once you'v
- On Oct 31, 2017, at 6:00 PM, Austin S. Hemmelgarn ahferro...@gmail.com
wrote:
> Assuming you're careful about how you install it (that is, put it in a
> custom prefix that isn't in $PATH), you could always build a local
> version of Python. Once you've got that, it's pretty trivial to chan
On 10/31/17, 9:48 AM, "David Sterba" wrote:
> The current default for the compression file flag is 'zlib', the zstd
> patch silently changed that to zstd. Though the choice of zlib might not
> be the best one, we should keep the backward compatibility.
Sorry about that, I didn't intentionally cha
On 2017-10-31 14:51, Andrei Borzenkov wrote:
31.10.2017 20:45, Austin S. Hemmelgarn пишет:
On 2017-10-31 12:23, ST wrote:
Hello,
I've recently learned about btrfs and consider to utilize for my needs.
I have several questions in this regard:
I manage a dedicated server remotely and have some
From: Filipe Manana
The patch from commit 7e3b975a0f92 ("Btrfs: fix reported number of inode
blocks") introduced a regression where if we do a buffered write starting
at position equal to or greater than the file's size and then stat(2) the
file before writeback is triggered, the number of used b
From: Filipe Manana
During a buffered IO write, we can have an extent state that we got when
we locked the range (if the range starts at an offset lower than eof), so
always pass it to btrfs_dirty_pages() so that setting the delalloc bit
in the range does not need to do a full search in the inode
31.10.2017 20:45, Austin S. Hemmelgarn пишет:
> On 2017-10-31 12:23, ST wrote:
>> Hello,
>>
>> I've recently learned about btrfs and consider to utilize for my needs.
>> I have several questions in this regard:
>>
>> I manage a dedicated server remotely and have some sort of script that
>> installs
All callers use GFP_NOFS, we don't have to pass it as an argument. The
built-in tests pass GFP_KERNEL, but they run only at module load time
and NOFS works there as well.
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.c | 10 +-
fs/btrfs/extent_io.h | 10 --
f
Use __clear_extent_bit directly in case we want to pass unknown
gfp flags. Otherwise all clear_extent_bit callers use GFP_NOFS, so we
can sink them to the function and reduce argument count, at the cost
that __clear_extent_bit has to be exported.
Signed-off-by: David Sterba
---
fs/btrfs/extent_i
There's only one callsite with GFP_NOFS.
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.h | 4 ++--
fs/btrfs/inode.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index bc9ebc858fae..e6987b050964 100644
--- a/fs/btrfs/e
This callback is called directly from VFS, no locks are held at the
allocation time.
Signed-off-by: David Sterba
---
fs/btrfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 8de8b38ee22f..9ac796f98c9e 100644
--- a/fs/btrfs/ino
David Sterba (4):
btrfs: prepare to drop gfp mask parameter from clear_extent_bit
btrfs: sink gfp parameter to clear_extent_bit
btrfs: sink gfp parameter to clear_extent_uptodate
btrfs: use GFP_KERNEL in btrfs_alloc_inode
fs/btrfs/extent_io.c | 16
fs/btrfs/extent
Split the conditions a bit.
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 6e45751ed957..3af2a7fd2d05 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -905,13
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index f206e83d4f52..75aed8ec64bd 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2344,17 +2344,15 @@ int btrfs_init_ne
Cleanups for device locking and documentation of the various mutexes.
Patch 1 is a bugfix that could be considered for 4.15 as we could leak bios
under some rare condition, but so far this hasn't been reported so I don't rate
is as critical.
David Sterba (11):
btrfs: add missing device::flush_bi
Make it clear that it is an RCU helper, we want to use the name
free_device for a wrapper freeing all device members.
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 08
The dev_alloc_list list could be protected by various mutexes,
depending on the context. The list tracks devices that can take part of
allocating new chunks, so the closest mutex is chunk_mutex. Adding a new
device from inside the ADD_DEV ioctl will need device_list_mutex and
registering a new devi
Overview of the main locks protecting various device-related structures.
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c | 66 ++
1 file changed, 66 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 75aed8ec64bd..098a
A helper to free a device and all it's dynamically allocated members,
like the rcu_string name or flush_bio. This is going to replace all
open coded places.
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs
We don't need to use the mutex as we do not modify the devices nor the
list itself and just read some information:
does not change during device lifetime:
- devid
- uuid
- name (ie. the path)
may change in parallel to the ioctl call, but can lead only to reporting
inacurracy:
- bytes_used
- total
We don't need to use the mutex as we do not modify the devices nor the
list itself and just read information about device counts.
Move copying fsid out of the protected section, not applicable to RCU
same as the rest of the retrieved information.
Signed-off-by: David Sterba
---
fs/btrfs/ioctl.c
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c | 39 +++
1 file changed, 11 insertions(+), 28 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 35c546aade83..f206e83d4f52 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -19
We take the fs_devices::device_list_mutex mutex in write_all_supers
which will prevent any add/del changes to the device list. Therefore we
don't need to use the RCU variant list_for_each_entry_rcu in any of the
called functions.
Signed-off-by: David Sterba
---
fs/btrfs/disk-io.c | 9 +
This fixes potential bio leaks, in several error paths. Unfortunatelly
the device structure freeing is opencoded in many places and I missed
them when introducing the flush_bio.
Most of the time, devices get freed through call_rcu(..., free_device),
so it at least it's not that easy to hit the lea
On 2017-10-31 12:23, ST wrote:
Hello,
I've recently learned about btrfs and consider to utilize for my needs.
I have several questions in this regard:
I manage a dedicated server remotely and have some sort of script that
installs an OS from several images. There I can define partitions and
the
On 2017-10-31 12:54, Lentes, Bernd wrote:
- On Oct 31, 2017, at 2:59 PM, Austin S. Hemmelgarn ahferro...@gmail.com
wrote:
Hi Austin,
thanks for your effort. What are the minimum prerequesties for kernel and
btrfsprogs for that script ?
Do you think it will run on my old SLES 11 SP4 ?
Dep
- On Oct 31, 2017, at 2:59 PM, Austin S. Hemmelgarn ahferro...@gmail.com
wrote:
>> Hi Austin,
>>
>> thanks for your effort. What are the minimum prerequesties for kernel and
>> btrfsprogs for that script ?
>> Do you think it will run on my old SLES 11 SP4 ?
> Dependency-wise, it needs:
>
>
The current default for the compression file flag is 'zlib', the zstd
patch silently changed that to zstd. Though the choice of zlib might not
be the best one, we should keep the backward compatibility.
The incompat bit for zstd is not set, so this could lead to a filesystem
with a zstd compressio
Hello,
I've recently learned about btrfs and consider to utilize for my needs.
I have several questions in this regard:
I manage a dedicated server remotely and have some sort of script that
installs an OS from several images. There I can define partitions and
their FSs.
1. By default the script
Hello,
I've recently learned about btrfs and consider to utilize for my needs.
I have several questions in this regard:
I manage a dedicated server remotely and have some sort of script that
installs an OS from several images. There I can define partitions and
their FSs.
1. By default the script
On 2017-10-31 23:18, Tomasz Chmielewski wrote:
On a different server, however, it failed badly:
# time btrfs balance start /srv
WARNING:
Full balance without filters requested. This operation is very
intense and takes potentially very long. It is recommended to
use the
A new version of btrfs-subv-backup has just been uploaded to github.
Yes, I know I skipped v0.2b, I actually did upload a version v0.2b, I
just forgot to post anything about it here...
Changes since the last time I posted here:
v0.2b:
* Updated the LICENSE file so that GitHub properly reco
On 31.10.2017 04:11, Anand Jain wrote:
>
>
> 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
>>> o
On 2017-09-18 17:20, Tomasz Chmielewski wrote:
# df -h /var/lib/lxd
FWIW, standard (aka util-linux) df is effectively useless in a
situation
such as this, as it really doesn't give you the information you need
(it
can say you have lots of space available, but if btrfs has all of it
allocated
On 31.10.2017 14:59, Anand Jain wrote:
> btrfs_async_submit_limit() would return the q depth to be 256, however
> when we are using it we are making it 2/3 times of it. So instead let
> the function return the final computed value.
>
> Signed-off-by: Anand Jain
Could you put a bit info about w
On 2017-10-31 08:40, Lentes, Bernd wrote:
- Am 26. Okt 2017 um 15:32 schrieb Austin S. Hemmelgarn
ahferro...@gmail.com:
As previously mentioned on the list, I've written up a script to back up
BTRFS subvolume structures in regular file-based backups. As of right
now, it's still a bit ro
- Am 26. Okt 2017 um 15:32 schrieb Austin S. Hemmelgarn
ahferro...@gmail.com:
> As previously mentioned on the list, I've written up a script to back up
> BTRFS subvolume structures in regular file-based backups. As of right
> now, it's still a bit rough around the edges, but it's cleaned
Build with musl libc needs the sys/types.h header for the dev_t type,
since this header is not included indirectly. This fixes the following
build failure:
In file included from convert/source-fs.c:23:0:
./convert/source-fs.h:112:1: error: unknown type name ‘dev_t’
dev_t decode_dev(u32 dev);
^~~
btrfs_async_submit_limit() would return the q depth to be 256, however
when we are using it we are making it 2/3 times of it. So instead let
the function return the final computed value.
Signed-off-by: Anand Jain
---
fs/btrfs/disk-io.c | 6 --
fs/btrfs/volumes.c | 1 -
2 files changed, 4 ins
On 2017-10-31 01:57, Marat Khalili wrote:
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 tec
On 2017年10月31日 18:27, Nikolay Borisov wrote:
>
>
> On 31.10.2017 12:09, Qu Wenruo wrote:
>>
>>
>> On 2017年10月31日 16:47, Nikolay Borisov wrote:
>>>
>>>
>>> On 31.10.2017 10:28, Qu Wenruo wrote:
For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
key objectid and ke
On 2017年10月31日 16:43, Gu Jinxiang wrote:
> Add support for running the tools from a given path
> (for example,/usr/bin) by setting $EXEC while running tests.
>
> Achieved:
> Specify the location of binary and run test like this:
> $ make EXEC=/usr/bin/ test
Any special reason to test system ins
On 31.10.2017 12:09, Qu Wenruo wrote:
>
>
> On 2017年10月31日 16:47, Nikolay Borisov wrote:
>>
>>
>> On 31.10.2017 10:28, Qu Wenruo wrote:
>>> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
>>> key objectid and key offset is just half of the UUID.
>>>
>>> However we just
On 2017年10月31日 16:47, Nikolay Borisov wrote:
>
>
> On 31.10.2017 10:28, Qu Wenruo wrote:
>> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
>> key objectid and key offset is just half of the UUID.
>>
>> However we just print the key as %llu, which is converted from litt
Some parameter of trans is not used indeed.
Let's remove them.
Signed-off-by: Gu Jinxiang
---
cmds-check.c | 9 -
ctree.h | 3 +--
extent-tree.c | 18 --
3 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index a6198bad..
Some variable is never used.
Remove them.
Signed-off-by: Gu Jinxiang
---
Android.mk | 1 -
Makefile | 2 --
2 files changed, 3 deletions(-)
diff --git a/Android.mk b/Android.mk
index 958b8bd7..de71a5d1 100644
--- a/Android.mk
+++ b/Android.mk
@@ -38,7 +38,6 @@ libbtrfs_headers := send-stream.
Patch 1 just remove the redundant function add_qgroup.
Patch 2 separate QGROUP_INFO/QGROUP_LIMIT/QGROUP_RELATION process from
the update_qgroup.
Patch 3 mainly the coding style adjustment.
Lu Fengqi (3):
btrfs-progs: qgroup: cleanup the redundant function add_qgroup
btrfs-progs: qgroup: split
The function update_qgroup has too many arguments that are too difficult
to use. Therefore, split it to update_qgroup_info, update_qgroup_limit,
update_qgroup_relation.
Signed-off-by: Lu Fengqi
---
qgroup.c | 163 +++
1 file changed, 81
1. Use goto instead of while (1) to reduce the level of indentation
2. Replace the if statement with the switch statement
3. move the BTRFS_IOC_TREE_SEARCH ioctl error handler to __qgroup_search
Signed-off-by: Lu Fengqi
---
cmds-qgroup.c | 4 --
qgroup.c | 152
There are reusable parts between update_qgroup and add_qgroup. So
introduce the function get_or_add_qgroup and use update_qgroup instead
of add_qgroup.
No functional changes.
Signed-off-by: Lu Fengqi
---
qgroup.c | 119 ++-
1 file chang
On 31.10.2017 10:28, Qu Wenruo wrote:
> For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
> key objectid and key offset is 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 traditiona
Use EXEC instead of TOP when judge whether where is executable files.
And set EXEC to TOP when it is not defined in top level test script.
Signed-off-by: Gu Jinxiang
---
tests/cli-tests.sh | 2 ++
tests/common | 18 --
tests/convert-tests.sh | 2 ++
tests/fsck-tes
When EXEC parameter is set, do not build this tool.
run the test tool with a given path.(/usr/bin, /usr/local/bin)
Signed-off-by: Gu Jinxiang
---
Makefile| 32 +++-
tests/README.md | 10 ++
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a
Modify script of every test case to use executable file of the
given path(EXEC), except btrfs-corrupt-block and fssum, because
they are internal tools and will not be installed.
Signed-off-by: Gu Jinxiang
---
tests/cli-tests/001-btrfs/test.sh | 20
.../cli-tests/002-bal
Add support for running the tools from a given path
(for example,/usr/bin) by setting $EXEC while running tests.
Achieved:
Specify the location of binary and run test like this:
$ make EXEC=/usr/bin/ test
Not Achieved:
Can not run make in tests/ directory.
Because test-misc depends on fssum which
For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
key objectid and key offset is 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 t
On 2017年10月31日 15:41, Nikolay Borisov wrote:
>
>
> On 31.10.2017 09:35, Qu Wenruo wrote:
>>
>>
>> On 2017年10月31日 15:29, Nikolay Borisov wrote:
>>>
>>>
>>> On 31.10.2017 09:15, Nikolay Borisov wrote:
On 31.10.2017 06:03, Qu Wenruo wrote:
> For key type BTRFS_UUID_KEY_SUBVOL or
On 31.10.2017 09:35, Qu Wenruo wrote:
>
>
> On 2017年10月31日 15:29, Nikolay Borisov wrote:
>>
>>
>> On 31.10.2017 09:15, Nikolay Borisov wrote:
>>>
>>>
>>> On 31.10.2017 06:03, Qu Wenruo wrote:
For key type BTRFS_UUID_KEY_SUBVOL or BTRFS_UUID_KEY_RECEIVED_SUBVOL the
key objectid and key
On 2017年10月31日 15:29, Nikolay Borisov wrote:
>
>
> On 31.10.2017 09:15, Nikolay Borisov wrote:
>>
>>
>> On 31.10.2017 06: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 w
On 31.10.2017 09:15, Nikolay Borisov wrote:
>
>
> On 31.10.2017 06: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 litt
On 2017年10月31日 15:15, Nikolay Borisov wrote:
>
>
> On 31.10.2017 06: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 lit
On 31.10.2017 06: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
82 matches
Mail list logo