On 2016-07-05 14:56, Tomasz Chmielewski wrote:
Getting this lengthy output logged, and the fs mounter read-only after
a power outage.
Tried also 4.6.3, but it ends just alike.
Jul 5 02:04:20 bkp011 kernel: [ 799.298303] [ cut here
]
Jul 5 02:04:20 bkp011 kernel: [ 7
Getting this lengthy output logged, and the fs mounter read-only after a
power outage.
Tried also 4.6.3, but it ends just alike.
Jul 5 02:04:20 bkp011 kernel: [ 799.298303] [ cut here
]
Jul 5 02:04:20 bkp011 kernel: [ 799.298335] WARNING: CPU: 0 PID: 1896
at /home
Henk Slager posted on Mon, 04 Jul 2016 23:13:52 +0200 as excerpted:
> [Tomasz Kusmierz wrote...]
>> Problem is that stuff on this filesystem moves so slowly that it's hard
>> to remember historical events ... it's like AWS glacier. What I can
>> state with 100% certainty is that:
>> - files that
Hi Darrick,
On Thu, Jun 16, 2016 at 06:46:02PM -0700, Darrick J. Wong wrote:
> Hi all,
>
> This is the sixth revision of a patchset that adds to xfstests
> support for testing reverse-mappings of physical blocks to file and
> metadata (rmap); support for testing multiple file logical blocks to
>
On Tue, Jul 05, 2016 at 11:56:17AM +0800, Eryu Guan wrote:
> On Thu, Jun 16, 2016 at 06:48:01PM -0700, Darrick J. Wong wrote:
> > Run xfs_repair twice at the end of each test -- once to rebuild
> > the btree indices, and again with -n to check the rebuild work.
> >
> > Signed-off-by: Darrick J. Wo
On Thu, Jun 16, 2016 at 06:48:01PM -0700, Darrick J. Wong wrote:
> Run xfs_repair twice at the end of each test -- once to rebuild
> the btree indices, and again with -n to check the rebuild work.
>
> Signed-off-by: Darrick J. Wong
> ---
> common/rc |3 +++
> 1 file changed, 3 insertions(+)
04.07.2016 23:43, Chris Murphy пишет:
>
> Have you done a scrub on this file system and do you know if anything
> was fixed or if it always found no problem?
>
scrub on degraded RAID5 cannot fix anything by definition, because even
if scrub finds discrepancies, it does not have enough data to
re
If btrfs isn't in the path, this test will fail with:
[TEST/misc] 006-image-on-missing-device
failed: btrfs fi show /dev/loop0
test failed for case 006-image-on-missing-device
Makefile:226: recipe for target 'test-misc' failed
make: *** [test-misc] Error 1
Fix the test script by adding $TOP
On 2016-07-01 22:46, Henk Slager wrote:
> (email ends up in gmail spamfolder)
> On Fri, Jul 1, 2016 at 10:14 PM, Dmitry Katsubo wrote:
>> Hello everyone,
>>
>> Question #1:
>>
>> While doing defrag I got the following message:
>>
>> # btrfs fi defrag -r /home
>> ERROR: defrag failed on /home/user/
I just tried btrfs rescue chunk-recover (btrfs-progs 4.6) on new
Btrfs, 3x raid5 with 1 dev missing. I get:
[root@f24s ~]# btrfs rescue chunk-recover /dev/VG/2
Scanning: DONE in dev0, DONE in dev1
open with broken chunk error
Chunk tree recovery failed
So I don't think rescue chunk-recover can wo
On Mon, Jul 4, 2016 at 3:10 PM, Tomáš Hrdina wrote:
> http://sebsauvage.net/paste/?39c73a3440b2e903#WZnUJXNFPNz/fFuOK3QquVeOWQUopcCl0JabtuYMWew=
Both backup 0 and 1 have bad information for backup_fs_root.
backup_fs_root: 0 gen: 0 level: 0
Presumably it automatically tries backup 2 or 3 even
Am Mon, 4 Jul 2016 23:16:50 +0200
schrieb Kai Krakow :
> Am Sun, 3 Jul 2016 23:30:20 +0200
> schrieb Adam Borowski :
>
> > On Sun, Jul 03, 2016 at 04:15:02PM +0200, Henk Slager wrote:
> > [...]
> [...]
> > >
> > > I get:
> > > ERROR: cannot open ./dropbox: Text file busy
> > >
> > > whe
I did consider that, but:
- some files were NOT accessed by anything with 100% certainty (well if there
is a rootkit on my system or something in that shape than maybe yes)
- the only application that could access those files is totem (well Nautilius
checks extension -> directs it to totem) so i
Am Sun, 3 Jul 2016 23:30:20 +0200
schrieb Adam Borowski :
> On Sun, Jul 03, 2016 at 04:15:02PM +0200, Henk Slager wrote:
> [...]
> > >
> > > That is probably true. Files that are mapped into memory (like
> > > running executables) cannot be changed on disk. You could make a
> > > copy of that f
On Sun, Jul 3, 2016 at 1:36 AM, Tomasz Kusmierz wrote:
> Hi,
>
> My setup is that I use one file system for / and /home (on SSD) and a
> larger raid 10 for /mnt/share (6 x 2TB).
>
> Today I've discovered that 14 of files that are supposed to be over
> 2GB are in fact just 4096 bytes. I've checked
One disk got reallocated sectors in SMART, so i did extended smart test
and it passed. Then I ran scrub and it found nothing. Everything was ok.
After this, it was started another extended smart test, weekly
scheduled, and I thing that sometime during this, disk went offline.
Maybe problem can be,
2016-06-30 16:58 GMT+03:00 Timofey Titovets :
> 2016-06-30 14:57 GMT+03:00 Anand Jain :
>>
>>
>> Thanks for reporting.
>>
>> Right. Application shouldn't notice the EIO. First of all,
>> we are not stopping IO to the disk which is pulled out. The
>> below patches 11/13 and 12/13 fixes it.
>>
>> [P
On Mon, Jul 4, 2016 at 1:11 PM, Tomáš Hrdina wrote:
> Result from dmesg:
> http://sebsauvage.net/paste/?4e8e95b5eafbf675#ybToBzZ/WAoRjjugeH6N2YXZKEBlswaNI/J41GBmFYU=
[10849.041749] BTRFS info (device sda): allowing degraded mounts
[10849.041754] BTRFS info (device sda): disk space caching is enab
On Jul 2, 2016, at 1:18 AM, Pavel Raiskup wrote:
>
> There are optimizations in archivers (tar, rsync, ...) that rely on up2date
> st_blocks info. For example, in GNU tar there is optimization check [1]
> whether the 'st_size' reports more data than the 'st_blocks' can hold --> then
> tar consid
Result from dmesg:
http://sebsauvage.net/paste/?4e8e95b5eafbf675#ybToBzZ/WAoRjjugeH6N2YXZKEBlswaNI/J41GBmFYU=
sudo btrfs dev scan
Scanning for Btrfs filesystems
sudo btrfs fi show
warning, device 3 is missing
checksum verify failed on 12678831570944 found 3DC57E3E wanted 771D2379
checksum verify
On Mon, Jul 04, 2016 at 02:51:37PM +0800, Eryu Guan wrote:
> On Thu, Jun 16, 2016 at 06:47:42PM -0700, Darrick J. Wong wrote:
> > Test sharing blocks via reflink and dedupe between two different
> > mountpoints of the same filesystem. This shouldn't work, since
> > we don't allow cross-mountpoint
On Mon, Jul 4, 2016 at 12:54 PM, Tomáš Hrdina wrote:
> Degraded gives same result:
>
> sudo mount -t btrfs -o ro,degraded /dev/sda /shares
> mount: wrong fs type, bad option, bad superblock on /dev/sda,
>missing codepage or helper program, or other error
>
>In some cases useful inf
On Mon, Jul 4, 2016 at 12:09 PM, Tomáš Hrdina wrote:
> sudo mount -t btrfs -o ro,recovery /dev/sdc /shares
> mount: wrong fs type, bad option, bad superblock on /dev/sdc,
>missing codepage or helper program, or other error
>
>In some cases useful info is found in syslog - try
>
Hello,
one of my 3 disks failed in RAID5. After that, fs is unable to mount.
Any help on what to try next would be appreciated.
sudo btrfs version
btrfs-progs v4.6.1
-- I installed 4.6.1 just now. I ran rescue on 4.4
uname -a
Linux uncik-srv 4.4.0-24-generic #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC
On Sun, Jul 03, 2016 at 11:23:06PM +0200, Hans van Kranenburg wrote:
> BTRFS_IOC_LOGICAL_INO takes a btrfs_ioctl_logical_ino_args as argument,
> not a btrfs_ioctl_ino_path_args. The lines were probably copy/pasted
> when the code was written.
>
> Since btrfs_ioctl_logical_ino_args and btrfs_ioctl_
On Sun, Jul 03, 2016 at 05:40:10AM +0100, Salah Triki wrote:
> size contains the value returned by posix_acl_from_xattr(), which
> returns -ERANGE, -ENODATA, zero, or an integer greater than zero. So
> replace -ENOENT by -ERANGE.
>
> Signed-off-by: Salah Triki
Reviewed-by: David Sterba
--
To un
On Wed, Jun 29, 2016 at 01:15:10PM +0800, Wang Xiaoguang wrote:
> When running fstests generic/068, sometimes we got below WARNING:
> xfs_io D 8800331dbb20 0 6697 6693 0x0080
> 8800331dbb20 88007acfc140 880034d895c0 8800331dc000
> 880032d243e8 f
On Wed, Jun 29, 2016 at 01:12:16PM +0800, Wang Xiaoguang wrote:
Can you please describe in more detail what is this patch fixing?
> Signed-off-by: Wang Xiaoguang
> ---
> fs/btrfs/extent-tree.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/extent-tree.c b
On Tue, Jun 28, 2016 at 06:55:48PM -0700, Liu Bo wrote:
> @@ -5238,6 +5256,10 @@ static void tree_move_down(struct btrfs_root *root,
> path->slots[*level]);
> path->slots[*level - 1] = 0;
> (*level)--;
> +
> + if (IS_ERR(path->nodes[*level - 1])
On Tue, Jun 28, 2016 at 01:44:38PM -0700, Liu Bo wrote:
> I got this warning while mounting a btrfs image,
>
> [ 3020.509606] [ cut here ]
> [ 3020.510107] WARNING: CPU: 3 PID: 5581 at lib/idr.c:1051
> ida_remove+0xca/0x190
> [ 3020.510853] ida_remove called for id=42 whic
On Fri, Jun 17, 2016 at 01:37:49PM -0700, Mark Fasheh wrote:
> Now that we can verify all qgroups, we can write the corrected qgroups out
> to disk when '--repair' is specified. The qgroup status item is also updated
> to clear any out-of-date state. The repair_ functions were modeled after the
> i
On 07/01/2016 08:38 PM, Tejun Heo wrote:
> On Fri, Jul 01, 2016 at 12:00:50PM +0200, Jan Kara wrote:
>> Hello,
>>
>> On Thu 30-06-16 14:18:14, Nikolay Borisov wrote:
>>> In light of the discussion in https://patchwork.kernel.org/patch/9187411/
>>> and
>>> the discussion at
>>> https://groups.g
On Thu, Jun 30, 2016 at 05:24:26PM +0800, Qu Wenruo wrote:
> Patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs.git dedupe_20160630
>
> Inband dedupe(in-memory backend only) ioctl support for btrfs-progs.
>
> User/reviewer/tester can still use previous btrfs-progs pa
On Thu, Jun 23, 2016 at 03:26:03PM -0400, je...@suse.com wrote:
> From: Jeff Mahoney
>
> While running xfstests generic/291, which creates a single file populated
> with reflinks to the same extent, I found that fsck had been running for
> hours. perf top lead me to find_data_backref as the culp
On Mon, Jul 04, 2016 at 02:13:18PM +0200, David Sterba wrote:
> On Sun, Jul 03, 2016 at 11:22:26PM +0200, Hans van Kranenburg wrote:
> > BTRFS_IOC_LOGICAL_INO takes a btrfs_ioctl_logical_ino_args as argument,
> > not a btrfs_ioctl_ino_path_args. The lines were probably copy/pasted
> > when the code
On Sun, Jul 03, 2016 at 11:22:26PM +0200, Hans van Kranenburg wrote:
> BTRFS_IOC_LOGICAL_INO takes a btrfs_ioctl_logical_ino_args as argument,
> not a btrfs_ioctl_ino_path_args. The lines were probably copy/pasted
> when the code was written.
>
> Since btrfs_ioctl_logical_ino_args and btrfs_ioctl_
On Fri, Jul 01, 2016 at 01:26:25PM +0800, Wang Xiaoguang wrote:
> When cleanup_temp_chunks() removes block groups, it forgot to update
> mkfs_allocation accordingly, fix this.
>
> Signed-off-by: Wang Xiaoguang
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-bt
On Mon, Jun 27, 2016 at 03:50:10PM +0800, Qu Wenruo wrote:
> Btrfs_record_file_extent() will split extents using max extent size(128M).
> It works well for real file extents, but not that well for large
> hole extent, as hole doesn't have extent size limit.
>
> In that case, it will only insert on
On Sat, Jun 25, 2016 at 12:47:29AM +0100, Luis Henriques wrote:
> The usage of 'source' is a bashism, and '.' should be used instead. This
> is causing fuzz-tests/001-simple-unmounted to fail in systems where
> /bin/sh isn't bash:
>
> [TEST/fuzz] 001-simple-unmounted
> ./test.sh: 5: ./test.
On Sat, Jul 2, 2016 at 7:03 PM, Chris Murphy wrote:
> On Sat, Jul 2, 2016 at 9:07 AM, Hans van Kranenburg
> wrote:
>
>>
>> Also, the behaviour of *always* creating a new empty block group before
>> starting to work (which makes it impossible to free up space on a fully
>> allocated filesystem wit
40 matches
Mail list logo