Hi Tomasz,
Thanks for the response! I should clear some things up, though.
On 07/06/2016 03:59 PM, Tomasz Kusmierz wrote:
On 6 Jul 2016, at 23:14, Corey Coughlin wrote:
Hi all,
Hoping you all can help, have a strange problem, think I know what's going
on, but could use some verificat
On Wed, Jul 6, 2016 at 8:24 PM, Tomasz Kusmierz wrote:
> you are throwing a lot of useful data, maybe diverting some of it into wiki ?
> you know, us normal people might find it useful for making educated choice in
> some future ? :)
There is a wiki, and it's difficult for keep up to date as i
On 7/6/16 8:35 AM, Holger Hoffstätte wrote:
> On 07/06/16 14:25, Wang Shilong wrote:
...
>> After patch, it will look like:
>>Total Exclusive Set shared Filename
>> skipping not btrfs dir/file: boot
>> skipping not btrfs dir/file: dev
>> skipping not btrfs dir/file: proc
>> skipping not b
hello,
On 07/06/2016 08:27 PM, Holger Hoffstätte wrote:
On 07/06/16 12:37, Wang Xiaoguang wrote:
Below test scripts can reproduce this false ENOSPC:
#!/bin/bash
dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128
dev=$(losetup --show -f fs.img)
mkfs.btrfs -f -M
hello,
On 07/07/2016 03:54 AM, Liu Bo wrote:
On Wed, Jul 06, 2016 at 06:37:52PM +0800, Wang Xiaoguang wrote:
In prealloc_file_extent_cluster(), btrfs_check_data_free_space() uses
wrong file offset for reloc_inode, it uses cluster->start and cluster->end,
which indeed are extent's bytenr. The co
> On 7 Jul 2016, at 02:46, Chris Murphy wrote:
>
Chaps, I didn’t wanted this to spring up as a performance of btrfs argument,
BUT
you are throwing a lot of useful data, maybe diverting some of it into wiki ?
you know, us normal people might find it useful for making educated choice in
some
Btrfs_read_block_groups() function is the most time consuming function
if the fs is large and filled with small extents.
For a btrfs filled with 100,000,000 16K sized files, mount the fs takes
about 10 seconds.
While ftrace shows that, btrfs_read_block_groups() takes about 9
seconds, taking up 90
On Wed, Jul 6, 2016 at 5:22 PM, Kai Krakow wrote:
> The current implementation of RAID0 in btrfs is probably not very
> optimized. RAID0 is a special case anyways: Stripes have a defined
> width - I'm not sure what it is for btrfs, probably it's per chunk, so
> it's 1GB, maybe it's 64k **.
Strip
Am Thu, 7 Jul 2016 00:51:16 +0100
schrieb Tomasz Kusmierz :
> > On 7 Jul 2016, at 00:22, Kai Krakow wrote:
> >
> > Am Wed, 6 Jul 2016 13:20:15 +0100
> > schrieb Tomasz Kusmierz :
> >
> >> When I think of it, I did move this folder first when filesystem
> >> was RAID 1 (or not even RAID at all
> On 7 Jul 2016, at 00:22, Kai Krakow wrote:
>
> Am Wed, 6 Jul 2016 13:20:15 +0100
> schrieb Tomasz Kusmierz :
>
>> When I think of it, I did move this folder first when filesystem was
>> RAID 1 (or not even RAID at all) and then it was upgraded to RAID 1
>> then RAID 10. Was there a faulty bal
On Thu, Jul 07, 2016 at 09:13:40AM +1000, Dave Chinner wrote:
> On Mon, Jul 04, 2016 at 09:11:34PM -0700, Darrick J. Wong wrote:
> > 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
Am Wed, 6 Jul 2016 13:20:15 +0100
schrieb Tomasz Kusmierz :
> When I think of it, I did move this folder first when filesystem was
> RAID 1 (or not even RAID at all) and then it was upgraded to RAID 1
> then RAID 10. Was there a faulty balance around August 2014 ? Please
> remember that I’m using
On Mon, Jul 04, 2016 at 09:11:34PM -0700, Darrick J. Wong wrote:
> 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
> On 6 Jul 2016, at 23:14, Corey Coughlin wrote:
>
> Hi all,
>Hoping you all can help, have a strange problem, think I know what's going
> on, but could use some verification. I set up a raid1 type btrfs filesystem
> on an Ubuntu 16.04 system, here's what it looks like:
>
> btrfs fi show
On Tue, Jul 05, 2016 at 12:31:30PM +0800, Eryu Guan wrote:
> 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
> On 6 Jul 2016, at 22:41, Henk Slager wrote:
>
> On Wed, Jul 6, 2016 at 2:20 PM, Tomasz Kusmierz
> wrote:
>>
>>> On 6 Jul 2016, at 02:25, Henk Slager wrote:
>>>
>>> On Wed, Jul 6, 2016 at 2:32 AM, Tomasz Kusmierz
>>> wrote:
On 6 Jul 2016, at 00:30, Henk Slager wrote:
>>
Hi all,
Hoping you all can help, have a strange problem, think I know
what's going on, but could use some verification. I set up a raid1 type
btrfs filesystem on an Ubuntu 16.04 system, here's what it looks like:
btrfs fi show
Label: none uuid: 597ee185-36ac-4b68-8961-d4adc13f95d4
To
On Wed, Jul 6, 2016 at 2:20 PM, Tomasz Kusmierz wrote:
>
>> On 6 Jul 2016, at 02:25, Henk Slager wrote:
>>
>> On Wed, Jul 6, 2016 at 2:32 AM, Tomasz Kusmierz
>> wrote:
>>>
>>> On 6 Jul 2016, at 00:30, Henk Slager wrote:
>>>
>>> On Mon, Jul 4, 2016 at 11:28 PM, Tomasz Kusmierz
>>> wrote:
>>>
>
On Wed, Jul 6, 2016 at 1:15 PM, Austin S. Hemmelgarn
wrote:
> On 2016-07-06 14:45, Chris Murphy wrote:
>> I think it's statistically 0 people changing this from default. It's
>> people with drives that have no SCT ERC support, used in raid1+, who
>> happen to stumble upon this very obscure work a
On Wed, Jul 6, 2016 at 1:17 PM, Austin S. Hemmelgarn
wrote:
> In bash or most other POSIX compliant shells, you can run this:
> echo $?
> to get the return code of the previous command.
>
> In your case though, it may be reporting the FS ready because it had already
> seen all the devices, IIUC,
On Wed, Jul 06, 2016 at 06:37:52PM +0800, Wang Xiaoguang wrote:
> In prealloc_file_extent_cluster(), btrfs_check_data_free_space() uses
> wrong file offset for reloc_inode, it uses cluster->start and cluster->end,
> which indeed are extent's bytenr. The correct value should be
> cluster->[start|end
On 2016-07-06 14:23, Chris Murphy wrote:
On Wed, Jul 6, 2016 at 12:04 PM, Austin S. Hemmelgarn
wrote:
On 2016-07-06 13:19, Chris Murphy wrote:
On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov
wrote:
3) can we query btrfs whether it is mountable in degraded mode?
according to documentation,
On 2016-07-06 14:45, Chris Murphy wrote:
On Wed, Jul 6, 2016 at 11:18 AM, Austin S. Hemmelgarn
wrote:
On 2016-07-06 12:43, Chris Murphy wrote:
So does it make sense to just set the default to 180? Or is there a
smarter way to do this? I don't know.
Just thinking about this:
1. People who a
On Wed, Jul 6, 2016 at 12:24 PM, Andrei Borzenkov wrote:
> On Wed, Jul 6, 2016 at 8:19 PM, Chris Murphy wrote:
>>
>> I'm mainly concerned with rootfs. And I'm mainly concerned with a very
>> simple 2 disk raid1. With a simple user opt in using
>> rootflags=degraded, it should be possible to boot
On Wed, Jul 6, 2016 at 11:18 AM, Austin S. Hemmelgarn
wrote:
> On 2016-07-06 12:43, Chris Murphy wrote:
>> So does it make sense to just set the default to 180? Or is there a
>> smarter way to do this? I don't know.
>
> Just thinking about this:
> 1. People who are setting this somewhere will be
On Wed, Jul 6, 2016 at 9:23 PM, Chris Murphy wrote:
>>> [root@f24s ~]# btrfs fi show
>>> warning, device 2 is missing
>>> Label: none uuid: 96240fd9-ea76-47e7-8cf4-05d3570ccfd7
>>> Total devices 3 FS bytes used 2.26GiB
>>> devid3 size 50.00GiB used 3.01GiB path /dev/mapper/VG-3
>>>
On Wed, Jul 6, 2016 at 8:19 PM, Chris Murphy wrote:
>
> I'm mainly concerned with rootfs. And I'm mainly concerned with a very
> simple 2 disk raid1. With a simple user opt in using
> rootflags=degraded, it should be possible to boot the system. Right
> now it's not possible. Maybe just deleting 6
On Wed, Jul 6, 2016 at 12:04 PM, Austin S. Hemmelgarn
wrote:
> On 2016-07-06 13:19, Chris Murphy wrote:
>>
>> On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov
>> wrote:
>>>
>>> 3) can we query btrfs whether it is mountable in degraded mode?
>>> according to documentation, "btrfs device ready" (wh
On Wed, Jul 6, 2016 at 11:12 AM, Gonzalo Gomez-Arrue Azpiazu
wrote:
> Hello,
>
> I had a RAID5 with 3 disks and one failed; now the filesystem cannot be
> mounted.
>
> None of the recommendations that I found seem to work. The situation
> seems to be similar to this one:
> http://www.spinics.net/
On Wed, Jul 6, 2016 at 11:50 AM, Tomáš Hrdina wrote:
> sudo mount -o ro /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
>dmesg | tail o
On 2016-07-06 13:19, Chris Murphy wrote:
On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov wrote:
3) can we query btrfs whether it is mountable in degraded mode?
according to documentation, "btrfs device ready" (which udev builtin
follows) checks "if it has ALL of it’s devices in cache for mount
sudo mount -o ro /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
dmesg | tail or so.
sudo mount -o ro,recovery /dev/sdc /shares
mount: wrong f
On Wed, Jul 6, 2016 at 3:55 AM, Stanislaw Kaminski
wrote:
> Device unallocated: 97.89GiB
There should be no problem creating any type of block group from this
much space. It's a bug.
I would try regression testing. Kernel 4.5.7 has some changes that may
or may not relate to this (
> On Jul 6, 2016, at 10:33 AM, Joerg Schilling
> wrote:
>
> "Austin S. Hemmelgarn" wrote:
>
>> On 2016-07-06 11:22, Joerg Schilling wrote:
>>>
>>>
>>> You are mistaken.
>>>
>>> stat /proc/$$/as
>>> File: `/proc/6518/as'
>>> Size: 2793472 Blocks: 5456 IO Block: 512regula
On Wed, Jul 6, 2016 at 3:51 AM, Andrei Borzenkov wrote:
> On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote:
>> I started a systemd-devel@ thread since that's where most udev stuff
>> gets talked about.
>>
>> https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html
>>
>
> Befo
On 2016-07-06 12:43, Chris Murphy wrote:
On Wed, Jul 6, 2016 at 5:51 AM, Austin S. Hemmelgarn
wrote:
On 2016-07-05 19:05, Chris Murphy wrote:
Related:
http://www.spinics.net/lists/raid/msg52880.html
Looks like there is some traction to figuring out what to do about
this, whether it's a udev
Hello,
I had a RAID5 with 3 disks and one failed; now the filesystem cannot be mounted.
None of the recommendations that I found seem to work. The situation
seems to be similar to this one:
http://www.spinics.net/lists/linux-btrfs/msg56825.html
Any suggestion on what to try next?
Thanks a lot b
On Wed, Jul 6, 2016 at 5:51 AM, Austin S. Hemmelgarn
wrote:
> On 2016-07-05 19:05, Chris Murphy wrote:
>>
>> Related:
>> http://www.spinics.net/lists/raid/msg52880.html
>>
>> Looks like there is some traction to figuring out what to do about
>> this, whether it's a udev rule or something that happ
"Austin S. Hemmelgarn" wrote:
> On 2016-07-06 11:22, Joerg Schilling wrote:
> > "Austin S. Hemmelgarn" wrote:
> >
> >>> It should be obvious that a file that offers content also has allocated
> >>> blocks.
> >> What you mean then is that POSIX _implies_ that this is the case, but
> >> does not
On Wed, Jul 06, 2016 at 05:42:33PM +0200, Holger Hoffstätte wrote:
> On 07/06/16 17:20, Hugo Mills wrote:
> > On Thu, Jul 07, 2016 at 12:16:01AM +0900, Wang Shilong wrote:
> >> On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte
> >> wrote:
> >>> On 07/06/16 14:25, Wang Shilong wrote:
> 'btrfs
On 2016-07-06 12:05, Austin S. Hemmelgarn wrote:
On 2016-07-06 11:22, Joerg Schilling wrote:
"Austin S. Hemmelgarn" wrote:
It should be obvious that a file that offers content also has
allocated blocks.
What you mean then is that POSIX _implies_ that this is the case, but
does not say whethe
On Wed, Jul 6, 2016 at 2:07 AM, Tomáš Hrdina wrote:
> Now with 3 disks:
>
> sudo btrfs check /dev/sda
> parent transid verify failed on 7008807157760 wanted 70175 found 70133
> parent transid verify failed on 7008807157760 wanted 70175 found 70133
> checksum verify failed on 7008807157760 found F1
On 2016-07-06 11:22, Joerg Schilling wrote:
"Austin S. Hemmelgarn" wrote:
It should be obvious that a file that offers content also has allocated blocks.
What you mean then is that POSIX _implies_ that this is the case, but
does not say whether or not it is required. There are all kinds of
c
On 07/06/16 17:20, Hugo Mills wrote:
> On Thu, Jul 07, 2016 at 12:16:01AM +0900, Wang Shilong wrote:
>> On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte
>> wrote:
>>> On 07/06/16 14:25, Wang Shilong wrote:
'btrfs file du' is a very useful tool to watch my system
file usage with snapsho
On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte
wrote:
> On 07/06/16 14:25, Wang Shilong wrote:
>> 'btrfs file du' is a very useful tool to watch my system
>> file usage with snapshot aware.
>>
>> when trying to run following commands:
>> [root@localhost btrfs-progs]# btrfs file du /
>> To
"Austin S. Hemmelgarn" wrote:
> > It should be obvious that a file that offers content also has allocated
> > blocks.
> What you mean then is that POSIX _implies_ that this is the case, but
> does not say whether or not it is required. There are all kinds of
> counterexamples to this too, pro
On Thu, Jul 07, 2016 at 12:16:01AM +0900, Wang Shilong wrote:
> On Wed, Jul 6, 2016 at 10:35 PM, Holger Hoffstätte
> wrote:
> > On 07/06/16 14:25, Wang Shilong wrote:
> >> 'btrfs file du' is a very useful tool to watch my system
> >> file usage with snapshot aware.
> >>
> >> when trying to run fol
On 2016-07-06 10:53, Joerg Schilling wrote:
Antonio Diaz Diaz wrote:
Joerg Schilling wrote:
POSIX requires st_blocks to be != 0 in case that the file contains data.
Please, could you provide a reference? I can't find such requirement at
http://pubs.opengroup.org/onlinepubs/9699919799/basede
On 07/06/2016 05:09 PM, Joerg Schilling wrote:
you concur that a delayed assignment of the "correct" value for
st_blocks while the contend of the file does not change is not permitted.
I'm not sure I agree even with that. A file system may undergo garbage
collection and compaction, for instance,
Paul Eggert wrote:
> On 07/06/2016 04:53 PM, Joerg Schilling wrote:
> > Antonio Diaz Diaz wrote:
> >
> >> >Joerg Schilling wrote:
> >>> > >POSIX requires st_blocks to be != 0 in case that the file contains
> >>> > >data.
> >> >
> >> >Please, could you provide a reference? I can't find such requ
On 07/06/2016 04:53 PM, Joerg Schilling wrote:
Antonio Diaz Diaz wrote:
>Joerg Schilling wrote:
> >POSIX requires st_blocks to be != 0 in case that the file contains data.
>
>Please, could you provide a reference? I can't find such requirement at
>http://pubs.opengroup.org/onlinepubs/9699919
Antonio Diaz Diaz wrote:
> Joerg Schilling wrote:
> > POSIX requires st_blocks to be != 0 in case that the file contains data.
>
> Please, could you provide a reference? I can't find such requirement at
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
blkcnt_t
Joerg Schilling wrote:
POSIX requires st_blocks to be != 0 in case that the file contains data.
Please, could you provide a reference? I can't find such requirement at
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
Thanks.
Antonio.
--
To unsubscribe from this list:
On 07/06/16 14:25, Wang Shilong wrote:
> 'btrfs file du' is a very useful tool to watch my system
> file usage with snapshot aware.
>
> when trying to run following commands:
> [root@localhost btrfs-progs]# btrfs file du /
> Total Exclusive Set shared Filename
> ERROR: Failed to lookup ro
'btrfs file du' is a very useful tool to watch my system
file usage with snapshot aware.
when trying to run following commands:
[root@localhost btrfs-progs]# btrfs file du /
Total Exclusive Set shared Filename
ERROR: Failed to lookup root id - Inappropriate ioctl for device
ERROR: cannot
On Wed, Jul 06, 2016 at 02:55:37PM +0300, Andrei Borzenkov wrote:
> On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn
> wrote:
> > On 2016-07-06 05:51, Andrei Borzenkov wrote:
> >>
> >> On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy
> >> wrote:
> >>>
> >>> I started a systemd-devel@ thread sinc
On 2016-07-06 08:39, Andrei Borzenkov wrote:
Отправлено с iPhone
6 июля 2016 г., в 15:14, Austin S. Hemmelgarn написал(а):
On 2016-07-06 07:55, Andrei Borzenkov wrote:
On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn
wrote:
On 2016-07-06 05:51, Andrei Borzenkov wrote:
On Tue, Jul 5
Отправлено с iPhone
> 6 июля 2016 г., в 15:14, Austin S. Hemmelgarn
> написал(а):
>
>> On 2016-07-06 07:55, Andrei Borzenkov wrote:
>> On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn
>> wrote:
>>> On 2016-07-06 05:51, Andrei Borzenkov wrote:
On Tue, Jul 5, 2016 at 11:10 PM, C
On 07/06/16 12:37, Wang Xiaoguang wrote:
> Below test scripts can reproduce this false ENOSPC:
> #!/bin/bash
> dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128
> dev=$(losetup --show -f fs.img)
> mkfs.btrfs -f -M $dev
> mkdir /tmp/mntpoint
> mount /dev/loop0
> On 6 Jul 2016, at 02:25, Henk Slager wrote:
>
> On Wed, Jul 6, 2016 at 2:32 AM, Tomasz Kusmierz
> wrote:
>>
>> On 6 Jul 2016, at 00:30, Henk Slager wrote:
>>
>> On Mon, Jul 4, 2016 at 11:28 PM, Tomasz Kusmierz
>> wrote:
>>
>> I did consider that, but:
>> - some files were NOT accessed b
On 2016-07-06 07:55, Andrei Borzenkov wrote:
On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn
wrote:
On 2016-07-06 05:51, Andrei Borzenkov wrote:
On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy
wrote:
I started a systemd-devel@ thread since that's where most udev stuff
gets talked about.
On Wed, Jul 6, 2016 at 2:45 PM, Austin S. Hemmelgarn
wrote:
> On 2016-07-06 05:51, Andrei Borzenkov wrote:
>>
>> On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy
>> wrote:
>>>
>>> I started a systemd-devel@ thread since that's where most udev stuff
>>> gets talked about.
>>>
>>>
>>> https://lists.fr
On 2016-07-05 19:05, Chris Murphy wrote:
Related:
http://www.spinics.net/lists/raid/msg52880.html
Looks like there is some traction to figuring out what to do about
this, whether it's a udev rule or something that happens in the kernel
itself. Pretty much the only hardware setup unaffected by th
"Austin S. Hemmelgarn" wrote:
> > A broken filesystem is a broken filesystem.
> >
> > If you try to change gtar to work around a specific problem, it may fail in
> > other situations.
> The problem with this is that tar is assuming things that are not
> guaranteed to be true. There is absolutel
On 2016-07-06 05:51, Andrei Borzenkov wrote:
On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote:
I started a systemd-devel@ thread since that's where most udev stuff
gets talked about.
https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html
Before discussing how to imple
On 2016-07-05 05:28, Joerg Schilling wrote:
Andreas Dilger wrote:
I think in addition to fixing btrfs (because it needs to work with existing
tar/rsync/etc. tools) it makes sense to *also* fix the heuristics of tar
to handle this situation more robustly. One option is if st_blocks == 0 then
t
Hi Hugo,
I agree that it seems to be a bug, and I'll be glad to help nail that
down - if only because I have no other drive to move the data to :-)
As for your suggestion - no change:
[root@archb3 stan]# mount | grep home
/dev/sda4 on /home type btrfs
(rw,relatime,nospace_cache,clear_cache,subvoli
Below test scripts can reproduce this false ENOSPC:
#!/bin/bash
dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=128
dev=$(losetup --show -f fs.img)
mkfs.btrfs -f -M $dev
mkdir /tmp/mntpoint
mount /dev/loop0 /tmp/mntpoint
cd mntpoint
In prealloc_file_extent_cluster(), btrfs_check_data_free_space() uses
wrong file offset for reloc_inode, it uses cluster->start and cluster->end,
which indeed are extent's bytenr. The correct value should be
cluster->[start|end] minus block group's start bytenr.
start bytenr cluster->start
|
On Wed, Jul 06, 2016 at 11:55:42AM +0200, Stanislaw Kaminski wrote:
> Hi,
> I am fighting with this since at least Monday - see
> https://superuser.com/questions/1096658/btrfs-out-of-space-even-though-there-should-be-10-left
>
> Here's the data:
> # uname -a
> Linux archb3 4.6.3-2-ARCH #1 PREEMP
Hi Alex,
Thank for having a look.
"You're trying to resize a fs that is probably already fully using the
block device it's on. I don't see anything incorrect happening here,
but I might be missing something."
This was just to show that I can't do this, I know that it is already
utilizing the entir
hello,
On 07/05/2016 01:35 AM, David Sterba wrote:
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 88003
hello,
On 07/05/2016 01:10 AM, David Sterba wrote:
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?
In original dump_space_info(), free space info is calculated by
info->total_bytes - info->bytes_used - info->byte
Hi,
I am fighting with this since at least Monday - see
https://superuser.com/questions/1096658/btrfs-out-of-space-even-though-there-should-be-10-left
Here's the data:
# uname -a
Linux archb3 4.6.3-2-ARCH #1 PREEMPT Wed Jun 29 07:15:33 MDT 2016
armv5tel GNU/Linux
# btrfs --version
btrfs-progs
On Tue, Jul 5, 2016 at 11:10 PM, Chris Murphy wrote:
> I started a systemd-devel@ thread since that's where most udev stuff
> gets talked about.
>
> https://lists.freedesktop.org/archives/systemd-devel/2016-July/037031.html
>
Before discussing how to implement it in systemd, we need to decide
wha
Now with 3 disks:
sudo btrfs check /dev/sda
parent transid verify failed on 7008807157760 wanted 70175 found 70133
parent transid verify failed on 7008807157760 wanted 70175 found 70133
checksum verify failed on 7008807157760 found F192848C wanted 1571393A
checksum verify failed on 7008807157760 f
76 matches
Mail list logo
