On Wed, May 15, 2019 at 04:02:21PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Run fsstress, fsync every file and directory, simulate a power failure and
> then verify the all files and directories exist, with the same data and
> metadata they had before the power failure.
>
> Th
On 2019/5/17 上午6:16, Michael Laß wrote:
> Hi.
>
> Today I managed to destroy my btrfs root filesystem using the following
> sequence of commands:
I don't have a root fs filled, but a btrfs with linux kernel with
compiled results filling 5G of a total 10G.
I'm using the that fs in my VM to try
On Thu, May 16, 2019 at 4:26 PM Michael Laß wrote:
>
> Hi.
>
> Today I managed to destroy my btrfs root filesystem using the following
> sequence of commands:
>
> sync
> btrfs balance start -dusage 75 -musage 75 /
> sync
> fstrim -v /
>
> Shortly after, the kernel spew out lots of messages like th
Hi.
Today I managed to destroy my btrfs root filesystem using the following
sequence of commands:
sync
btrfs balance start -dusage 75 -musage 75 /
sync
fstrim -v /
Shortly after, the kernel spew out lots of messages like the following:
BTRFS warning (device dm-5): csum failed root 257 ino 16
On Thu, May 16, 2019 at 4:37 AM Lee Fleming wrote:
> And a btrfs check gives the following:
>
> % btrfs check --repair /dev/mapper/vg-root
Why use repair? From the man page
Warning
Do not use --repair unless you are advised to do so by a developer
or an experienced use
On Thu, May 16, 2019 at 5:59 PM Theodore Ts'o wrote:
>
> On Thu, May 16, 2019 at 10:54:57AM +0100, Filipe Manana wrote:
> >
> > Haven't tried ext4 with 1 process only (instead of 4), but I can try
> > to see if it happens without concurrency as well.
>
> How many CPU's and how much memory were you
On Thu, May 16, 2019 at 04:54:42PM +0200, Axel Burri wrote:
> Trying to get the size of a subvolume created using "btrfs receive",
> I've come with a cute little script:
>
>SUBVOL=/path/to/subvolume
>CGEN=$(btrfs subvolume show "$SUBVOL" \
> | sed -n 's/\s*Gen at creation:\s*//p')
>
On 2019-05-16 10:54 a.m., Axel Burri wrote:
>
> Any thoughts? I'm willing to implement such a feature in btrfs-progs if
> this sounds reasonable to you.
>
BTRFS qgroups are where this is implemented. You have to enable quotas,
and leaving quotas enabled has lots of problems, (mostly performan
On Thu, May 16, 2019 at 10:54:57AM +0100, Filipe Manana wrote:
>
> Haven't tried ext4 with 1 process only (instead of 4), but I can try
> to see if it happens without concurrency as well.
How many CPU's and how much memory were you using? And I assume this
was using KVM/QEMU? How was it configu
On Thu, May 16, 2019 at 09:57:01AM +0300, Nikolay Borisov wrote:
>
>
> On 16.05.19 г. 0:36 ч., Zygo Blaxell wrote:
> > "Storm-of-soft-lockups" is a failure mode where btrfs puts all of the
> > CPU cores in kernel functions that are unable to make forward progress,
> > but also unwilling to releas
Trying to get the size of a subvolume created using "btrfs receive",
I've come with a cute little script:
SUBVOL=/path/to/subvolume
CGEN=$(btrfs subvolume show "$SUBVOL" \
| sed -n 's/\s*Gen at creation:\s*//p')
btrfs subvolume find-new "$SUBVOL" $((CGEN+1)) \
| cut -d' ' -f7 \
From: Filipe Manana
While logging an inode we follow its ancestors and for each one we mark
it as logged in the current transaction, even if we have not logged it.
As a consequence if we change an attribute of an ancestor, such as the
UID or GID for example, and then explicitly fsync it, we end u
On 2019/5/16 下午10:01, Nikolay Borisov wrote:
>
>
> On 16.05.19 г. 16:54 ч., Qu Wenruo wrote:
>>
>>
>> On 2019/5/16 下午9:45, Nikolay Borisov wrote:
>>>
>>>
>>> On 16.05.19 г. 16:41 ч., Qu Wenruo wrote:
On 2019/5/16 下午9:12, Nikolay Borisov wrote:
> When btrfs' 'filesystem' subcom
On 16.05.19 г. 16:54 ч., Qu Wenruo wrote:
>
>
> On 2019/5/16 下午9:45, Nikolay Borisov wrote:
>>
>>
>> On 16.05.19 г. 16:41 ч., Qu Wenruo wrote:
>>>
>>>
>>> On 2019/5/16 下午9:12, Nikolay Borisov wrote:
When btrfs' 'filesystem' subcommand is passed path to an image file it
currently fail
On 2019/5/16 下午9:45, Nikolay Borisov wrote:
>
>
> On 16.05.19 г. 16:41 ч., Qu Wenruo wrote:
>>
>>
>> On 2019/5/16 下午9:12, Nikolay Borisov wrote:
>>> When btrfs' 'filesystem' subcommand is passed path to an image file it
>>> currently fails since the code expects the image file is going to be
>>>
On 16.05.19 г. 16:41 ч., Qu Wenruo wrote:
>
>
> On 2019/5/16 下午9:12, Nikolay Borisov wrote:
>> When btrfs' 'filesystem' subcommand is passed path to an image file it
>> currently fails since the code expects the image file is going to be
>> recognised by libblkid (called from btrfs_scan_device
On 2019/5/16 下午9:12, Nikolay Borisov wrote:
> When btrfs' 'filesystem' subcommand is passed path to an image file it
> currently fails since the code expects the image file is going to be
> recognised by libblkid (called from btrfs_scan_devices()). This is not
> the case since libblkid only scan
This ensures that 'btrfs filesystem show' can correctly identify a
filesystem on a newly created local file.
Signed-off-by: Nikolay Borisov
---
tests/cli-tests/010-fi-show-on-new-file/test.sh | 16
1 file changed, 16 insertions(+)
create mode 100755 tests/cli-tests/010-fi-show-
When btrfs' 'filesystem' subcommand is passed path to an image file it
currently fails since the code expects the image file is going to be
recognised by libblkid (called from btrfs_scan_devices()). This is not
the case since libblkid only scan well-known locations under /dev.
Fix this by explicit
On 2019/5/16 下午8:57, David Sterba wrote:
> On Fri, May 03, 2019 at 08:30:54AM +0800, Qu Wenruo wrote:
>> Under certain condition, we could have strange file extent item in log
>> tree like:
>>
>> item 18 key (69599 108 397312) itemoff 15208 itemsize 53
>> extent data disk bytenr 0 nr 0
>>
On Fri, May 03, 2019 at 08:30:54AM +0800, Qu Wenruo wrote:
> Under certain condition, we could have strange file extent item in log
> tree like:
>
> item 18 key (69599 108 397312) itemoff 15208 itemsize 53
> extent data disk bytenr 0 nr 0
> extent data offset 0 nr 1844674407370954752
On Tue, May 14, 2019 at 03:58:04PM +0200, Johannes Thumshirn wrote:
> inspect-internal dump-superblock's load_and_dump_sb() already reads a
> super block from a file descriptor and places it into a 'struct
> btrfs_super_block'.
>
> For inspect-internal dump-csum we need this super block as well bu
On 16.05.19 г. 12:06 ч., Qu Wenruo wrote:
>
>
> On 2019/5/16 下午4:42, Nikolay Borisov wrote:
>> This series fixes the following use case:
>>
>> truncate -s 3g btrfs.img
>> mkfs.btrfs btrfs.img
>> btrrfs fi show .img
>> ERROR: not a valid btrfs filesystem: /root/btrfs.img
>>
>>
>> As evident thi
Currently, there's only check for fast crc32c implementation on X86,
based on the CPU flags. This is used to decide if checksumming should be
offloaded to worker threads or can be calculated by the caller.
As there are more architectures that implement a faster version of
crc32c (ARM, SPARC, s390,
After seeking advice on reddit I've been advised to post this problem
here. See
https://www.reddit.com/r/btrfs/comments/bp0awe/broken_btrfs_filesystem_following_a_reboot/
I have a root btrfs filesystem on top of mdadm raid10 and lvm. The
raid and lvm appear to be ok but the btrfs partition will n
On Thu, May 16, 2019 at 10:30 AM Theodore Ts'o wrote:
>
> On Wed, May 15, 2019 at 04:02:21PM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > Run fsstress, fsync every file and directory, simulate a power failure and
> > then verify the all files and directories exist, with the s
On Wed, May 15, 2019 at 04:02:21PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Run fsstress, fsync every file and directory, simulate a power failure and
> then verify the all files and directories exist, with the same data and
> metadata they had before the power failure.
>
> Th
Since no one seems to show any big interest in this issues, I've added
it for the records in https://bugzilla.kernel.org/show_bug.cgi?id=203621
Cheers,
Chris.
On 2019/5/16 下午4:42, Nikolay Borisov wrote:
> This series fixes the following use case:
>
> truncate -s 3g btrfs.img
> mkfs.btrfs btrfs.img
> btrrfs fi show .img
> ERROR: not a valid btrfs filesystem: /root/btrfs.img
>
>
> As evident this currently produces an error due to libblkid not recognisi
Commit 9678c54388b6 ("btrfs: Remove custom crc32c init code") removed the
btrfs_crc32c() function, because it was a duplicate of the crc32c() library
function we already have in the kernel.
Resurrect it as a shim wrapper over crc32c() to make following
transformations of the checksumming code in b
The CRC checksum in the free space cache is not dependant on the super
block's csum_type field but always a CRC32C.
So use btrfs_crc32c() and btrfs_crc32c_final() instead of btrfs_csum_data()
and btrfs_csum_final() for computing these checksums.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nik
Add a small helper for btrfs_print_data_csum_error() which formats the
checksum according to it's type for pretty printing.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
fs/btrfs/btrfs_inode.h | 28
1 file changed, 24 insertions(+), 4 deletions(
Currently btrfs is only supporting CRC32C as checksumming algorithm. As
this is about to change provide a function to validate the checksum type in
the superblock against all possible algorithms.
This makes adding new algorithms easier as there are fewer places to adjust
when adding new algorithms
Add boilerplate code for directly including the crypto framework.
This helps us flipping the switch for new algorithms.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 11 +++
fs/btrfs/disk-io.c | 49 ++
Now that we have factorerd out the superblock checksum type validation, we
can check for supported superblock checksum types before doing the actual
validation of the superblock read from disk.
This leads the path to further simplifications of btrfs_check_super_csum()
later on.
Signed-off-by: Joh
btrfs_print_data_csum_error() still assumed checksums to be 32 bit in size.
Make it size agnostic.
Signed-off-by: Johannes Thumshirn
---
fs/btrfs/btrfs_inode.h | 6 +++---
fs/btrfs/compression.c | 2 +-
fs/btrfs/inode.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --gi
btrfsic_test_for_metadata() directly calls the crc32c() library function
for calculating the CRC32C checksum, but then uses btrfs_csum_final() to
invert the result.
To ease further refactoring and development around checksumming in BTRFS
convert to calling btrfs_csum_data(), which is a wrapper aro
This patchset add support for adding new checksum types in BTRFS.
Currently BTRFS only supports CRC32C as data and metadata checksum, which is
good if you only want to detect errors due to data corruption in hardware.
But CRC32C isn't able cover other use-cases like de-duplication or
cryptographi
Now that we everything in place, we can add SHA-256 as another checksum
algorithm.
SHA-256 was taken as it was the cryptographically strongest algorithm that
can fit into the 32 Bytes we have left.
Signed-off-by: Johannes Thumshirn
---
Changes to v1:
- Select SHA-256 in KConfig
- Minimalize swi
BTRFS has the implicit assumption that a checksum in compressed_bio is 4
bytes. While this is true for CRC32C, it is not for any other checksum.
Change the data type to be a byte array and adjust loop index calculation
accordingly.
Signed-off-by: Johannes Thumshirn
---
fs/btrfs/compression.c |
Currently btrfs_csum_data() relied on the crc32c() wrapper around the crypto
framework for calculating the CRCs.
As we have our own crypto_shash structure in the fs_info now, we can
directly call into the crypto framework without going trough the wrapper.
This way we can even remove the btrfs_csu
Now that we have already checked for a valid checksum type before calling
btrfs_check_super_csum(), it can be simplified even further.
While at it get rid of the implicit size assumption of the resulting
checksum as well.
Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
---
Chang
BTRFS has the implicit assumption that a checksum in btrfs_orderd_sums is 4
bytes. While this is true for CRC32C, it is not for any other checksum.
Change the data type to be a byte array and adjust loop index calculation
accordingly.
Signed-off-by: Johannes Thumshirn
---
fs/btrfs/compression.c
Currently if a new filesystem is created and interrogated with we get
an error:
truncate -s 3g btrfs.img
mkfs.btrfs btrfs.img
btrfs fi show btrfs.img
ERROR: not a valid btrfs filesystem: /root/btrfs.img
The reason is that the image is not automatically recognised by libblkid
meani
This series fixes the following use case:
truncate -s 3g btrfs.img
mkfs.btrfs btrfs.img
btrrfs fi show .img
ERROR: not a valid btrfs filesystem: /root/btrfs.img
As evident this currently produces an error due to libblkid not recognising the
image file as a filesystem. This stems from the fact
Currently btrfs_scan_devices will only scan devices under /dev (and
some other places that libblkid understands). This may cause a btrfs
filesystem housed on a file to be missed when issuing certain commands.
This patch allow the caller to explicitly pass a path that should be
probed for a btrfs fi
This ensures that 'btrfs filesystem show' can correctly identify a
filesystem on a newly created local file.
Signed-off-by: Nikolay Borisov
---
tests/cli-tests/010-fi-show-on-new-file/test.sh | 16
1 file changed, 16 insertions(+)
create mode 100755 tests/cli-tests/010-fi-show-
On 16.05.19 г. 9:30 ч., Paul Jones wrote:
>
>> -Original Message-
>> From: linux-btrfs-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of David Sterba
>> Sent: Thursday, 16 May 2019 3:27 AM
>> To: Johannes Thumshirn
>> Cc: David Sterba ; Linux BTRFS Mailinglist > bt...@vger.ke
On Thu, May 16, 2019 at 11:16:38AM +0300, Nikolay Borisov wrote:
> It is labelled non-cryptographic, and is not meant to avoid intentional
> collisions (same digest for 2 different messages), or to prevent
> producing a message with predefined digest.
>
> This doesn't disqualify it, however we nee
On Wed, May 15, 2019 at 04:02:21PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
Nit:
> This tes has found already 2 bugs in btrfs, that caused mtime and ctime of
test? ^
--
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de
On 15.05.19 г. 18:02 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When replaying a log that contains a new file or directory name that needs
> to be added to its parent directory, we end up updating the mtime and the
> ctime of the parent directory to the current time after we have
On 15.05.19 г. 18:02 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> While logging an inode we follow its ancestors and for each one we mark
> it as logged in the current transaction, even if we have not logged it.
> As a consequence if we change an attribute of an ancestor, such as t
52 matches
Mail list logo
