Btrfs already skip store of data where compression didn't
free at least one byte. Let's make logic better and make check
that compression free at least one sector size
because in another case it useless to store this data compressed
Signed-off-by: Timofey Titovets
---
fs/btrfs/inode.c | 3 ++-
1
Logic already return error if compression
make data bigger, let's sync logic with zlib
and also return error if compressed size
are equal to input size
Signed-off-by: Timofey Titovets
---
fs/btrfs/lzo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/lzo.c b/fs/bt
First patch:
Sync comparison logic of compressed/uncompressed sizes from zlib to lzo
Second patch:
Force btrfs to not store data as compressed,
if compression will not free at least one sector size,
because it's useless in term of saving storage space and
reading data from disk, as a result produc
On Mon, May 15, 2017 at 07:00:23PM +0200, Philipp Hahn wrote:
> Running "btrfsck --repair /dev/sdd2" crashed as it can happen in
> (corrupted) file systems, that slot > nritems:
> > (gdb) bt full
> > #0 0x77020e71 in __memmove_sse2_unaligned_erms () from
> > /lib/x86_64-linux-gnu/libc.so.
2017-05-29 17:23 GMT+03:00 David Sterba :
> On Thu, May 25, 2017 at 09:12:20PM +0300, Timofey Titovets wrote:
>> Btrfs already skip store of data where compression didn't
>> free at least one byte. Let's make logic better and make check
>> that compression free at least one sector size
>> because i
On Thu, May 18, 2017 at 11:38:25AM +0800, Qu Wenruo wrote:
> The patchset can be fetched from my github:
> https://github.com/adam900710/btrfs-progs/tree/fs_info_refactor
>
> Which is based on v4.11-rc1.
>
> This quite scary patchset does a large refactoring (while still less than
> 500 LoC) to m
On Mon, May 15, 2017 at 04:27:39PM +0800, Qu Wenruo wrote:
> btrfs_check_chunk_valid() doesn't check if
> 1) chunk flag has conflicting flags
>For example chunk type DATA|METADATA|RAID1|RAID10 is completely
>invalid, while current check_chunk_valid() can't detect it.
> 2) num_stripes is inv
On Wed, May 17, 2017 at 02:41:31AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that we are able to create an image from a multiple devices fs, that
> we are able to restore that image into a single device and finally that we
> are able to mount it.
>
> Signed-off-by: Filipe
On 2017-05-29 02:21, Qu Wenruo wrote:
>
>
> At 05/27/2017 02:37 AM, Goffredo Baroncelli wrote:
>> Hi Qu,
>>
>> On 2017-05-25 08:21, Qu Wenruo wrote:
>>
>>> And since kernel scrub won't account P/Q corruption, it makes us quite
>>> hard to detect error like kernel screwing up P/Q when scrubbing.
>
On Thu, May 18, 2017 at 05:11:35PM -0700, Liu Bo wrote:
> On Wed, May 17, 2017 at 02:41:21AM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > We correctly build an image from a multiple devices filesystem but when
> > restoring the image into a single device we were missing updat
On Tue, May 16, 2017 at 12:01:53PM +0900, Tsutomu Itoh wrote:
> In btrfs-progs-v4.11-rc1, the following convert-tests failed.
>
> [TEST/conv] 008-readonly-image
> [TEST/conv] readonly image test, btrfs defaults
> failed: mke2fs -t ext4 -b 4096 -F /Build/btrfs-progs-v4.11-rc1/tests/te
On Fri, May 19, 2017 at 08:32:18AM +0800, Qu Wenruo wrote:
> At 05/18/2017 09:45 PM, David Sterba wrote:
> > On Thu, May 18, 2017 at 08:24:26AM +0800, Qu Wenruo wrote:
> +static inline void extent_changeset_init(struct extent_changeset
> *changeset)
> +{
> +changeset->b
This patch adds the name length verification to many places and in some
of them it looks unnecessary, as the directory item passes sanity checks
already. The verification should always happen when we read the input,
ie from disk, after search_slot etc. Then, it can be considered valid
and does not
On Mon, May 29, 2017 at 05:22:43PM +0200, David Sterba wrote:
> On Thu, May 25, 2017 at 10:09:06AM +0800, Su Yue wrote:
> > When reading out name from inode_ref, dir_item, it's possible that
> > corrupted name_len lead to read beyond boundary.
> >
> > Since there are already patches for btrfs-prog
On Thu, May 25, 2017 at 10:09:07AM +0800, Su Yue wrote:
> @@ -472,6 +474,15 @@ int verify_dir_item(struct btrfs_fs_info *fs_info,
> return 1;
> }
>
> + namelen = btrfs_dir_name_len(leaf, dir_item);
> + namelen_ret = btrfs_check_namelen(leaf, slot,
> +
On Thu, May 25, 2017 at 10:09:06AM +0800, Su Yue wrote:
> When reading out name from inode_ref, dir_item, it's possible that
> corrupted name_len lead to read beyond boundary.
>
> Since there are already patches for btrfs-progs, this is for btrfs.
>
> Introduce function btrfs_check_namelen, it sh
On Fri, May 19, 2017 at 03:08:22PM +0200, David Sterba wrote:
> On Thu, May 18, 2017 at 05:42:24PM -0700, Liu Bo wrote:
> > On Tue, May 16, 2017 at 07:10:38PM +0200, David Sterba wrote:
> > > flush_all_writes is an atomic but does not use the semantics at all,
> > > it's just on/off indicator, we c
On Fri, May 26, 2017 at 05:44:23PM -0600, Liu Bo wrote:
> Before this, we use 'filled' mode here, ie. if all range has been
> filled with EXTENT_DEFRAG bits, get to clear it, but if the defrag
> range joins the adjacent delalloc range, then we'll have EXTENT_DEFRAG
> bits in extent_state until rele
On Thu, May 25, 2017 at 09:12:19PM +0300, Timofey Titovets wrote:
> Fix copy paste typo in debug message for lzo.c, lzo is not deflate
>
> Signed-off-by: Timofey Titovets
Patch added, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ma
On Thu, May 25, 2017 at 09:12:20PM +0300, Timofey Titovets wrote:
> Btrfs already skip store of data where compression didn't
> free at least one byte. Let's make logic better and make check
> that compression free at least one sector size
> because in another case it useless to store this data com
On Sat, May 27, 2017 at 06:36:33AM +0800, Anand Jain wrote:
> Signed-off-by: Anand Jain
> ---
> Hi David,
> I note the original patch [1] is already queued so here I am sending
> a fix-up patch can you pls squash this to [1]
> [1]
>[PATCH 2/3 v2] btrfs: reduce arguments for decompress_bio
On Mon, May 29, 2017 at 09:48:19AM +0800, Qu Wenruo wrote:
>
>
> At 05/27/2017 04:20 AM, Liu Bo wrote:
> > On Fri, May 26, 2017 at 08:33:16PM +0200, David Sterba wrote:
> >> On Thu, May 25, 2017 at 06:26:31PM -0600, Liu Bo wrote:
> >>> Currently scrub only verify checksum of both metadata and dat
On Fri, May 26, 2017 at 12:49:25PM -0700, Liu Bo wrote:
> On Fri, May 26, 2017 at 07:08:31PM +0200, David Sterba wrote:
> > On Thu, May 25, 2017 at 06:39:52AM -0400, Jeff Layton wrote:
> > > Nothing checks its return value.
> >
> > I think we don't need to check the return value of
> > filemap_fda
On Mon, May 29, 2017 at 09:43:43AM +0300, Nikolay Borisov wrote:
> Commit 5f39d397dfbe ("Btrfs: Create extent_buffer interface
> for large blocksizes") refactored btrfs_leaf_data function to take
> extent_buffer rather than struct btrfs_leaf. However, as it turns out the
> parameter being passed is
On Fri, May 26, 2017 at 11:56:07AM +0300, Christoph Hellwig wrote:
> This series introduces a new blk_status_t error code type for the block
> layer so that we can have tigher control and explicit semantics for
> block layer errors.
>
> All but the last three patches are cleanups that lead to the
On Fri, May 26, 2017 at 11:56:12AM +0300, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Bart Van Assche
For the btrfs bits
Acked-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.ke
I'm not asking for a specific endorsement, but should I be considering
something like the seagate ironwolf or WD red drives?
You need two qualitative features from HDD for RAID usage:
1) being failfast (TLER in WD talk), and
2) be designed to tolerate vibrations from other disks in a box.
There
On Sun, May 28, 2017 at 09:38:26PM -0500, Goldwyn Rodrigues wrote:
>
>
> On 05/28/2017 04:31 AM, Christoph Hellwig wrote:
> > Despite my previous reviewed-by tag this will need another fix:
> >
> > xfs_file_iomap_begin needs to return EAGAIN if we don't have the extent
> > list in memoery alread
On Sun, May 28, 2017 at 09:38:27PM -0500, Goldwyn Rodrigues wrote:
> This effort focused on writes only.
>
> >From the point of view of the application/user, reads are usually
> required to complete with success. I don't see a scenario where reads()
> would need the nowait feature. If there is a u
On Sun 28-05-17 21:38:26, Goldwyn Rodrigues wrote:
> On 05/28/2017 04:31 AM, Christoph Hellwig wrote:
> > Despite my previous reviewed-by tag this will need another fix:
> >
> > xfs_file_iomap_begin needs to return EAGAIN if we don't have the extent
> > list in memoery already. E.g. something lik
30 matches
Mail list logo
