From: Zhao Lei
Btrfs will report NO_SPACE when we create and remove files for several times:
1: Create a single-dev btrfs fs with default option
2: Write a file into it to take up most fs space
3: Delete above file
4: Wait about 100s to let chunk removed
5: goto 2
Script is like following:
#!/b
From: Zhao Lei
Btrfs will report NO_SPACE when we create and remove files for several times:
1: Create a single-dev btrfs fs with default option
2: Write a file into it to take up most fs space
3: Delete above file
4: Wait about 100s to let chunk removed
5: goto 2
Script is like following:
#!/b
From: Zhao Lei
Btrfs will report NO_SPACE when we create and remove files for several times:
1: Create a single-dev btrfs fs with default option
2: Write a file into it to take up most fs space
3: Delete above file
4: Wait about 100s to let chunk removed
5: goto 2
Script is like following:
#!/b
2015-02-05 18:23 GMT+08:00 Filipe David Manana :
> On Wed, Feb 4, 2015 at 12:28 PM, Forrest Liu wrote:
>> Kernel BUG_ON when running following script on kernel 3.19-rc7
>>
>> mntpath=/btrfs
>> loopdev=/dev/loop0
>> filepath=/volume2/100g_image
>>
>> umount $mntpath
>> losetup -d $loopdev
>> trunca
On Fri, Feb 6, 2015 at 8:42 AM, Zhaolei wrote:
> From: Zhao Lei
>
> Btrfs will report NO_SPACE when we create and remove files for several times:
> 1: Create a single-dev btrfs fs with default option
> 2: Write a file into it to take up most fs space
> 3: Delete above file
> 4: Wait about 100s to
On Fri, Feb 6, 2015 at 8:42 AM, Zhaolei wrote:
> From: Zhao Lei
>
> Btrfs will report NO_SPACE when we create and remove files for several times:
> 1: Create a single-dev btrfs fs with default option
> 2: Write a file into it to take up most fs space
> 3: Delete above file
> 4: Wait about 100s to
Hi, Filipe
> > Reason:
> > Btrfs get free disk space by calling find_free_dev_extent() when
> > re-create chunk for write, but current code set search_commit_root
> > flag in searching tree, so disk spaces which was freed from dev_tree
> > but not commited can not get from find_free_dev_extent(),
Hi, Filipe
> This was already fixed by Forrest recently. See:
> https://patchwork.kernel.org/patch/5776231/
>
Thanks for notice, I overlooked the second half of his patch...
Please ignore it.
Thanks
Zhaolei
> > ---
> > fs/btrfs/volumes.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 de
There's a short time window where a race can happen between two or more
tasks that hold a transaction handle for the same transaction and where
one starts the transaction commit before the other tasks attempt to
split their pending ordered extents list into the transaction's pending
ordered extents
We can have two concurrent fsync operations against the same file
that target different ranges of the file, in which case both fsyncs
will process ordered extents that overlap both ranges. This allows
for a time window where a race can lead to those ordered extents
never getting their reference cou
On 02/06/2015 06:20 AM, Qu Wenruo wrote:
From: Lutz Vieweg
use case: You have two huge files on a btrfs, you assume they contain the same
bytes,
but you do not know for sure.
Is there a way to get a checksum of both files from btrfs with less effort than
reading the whole of both files and co
On Fri, Feb 06, 2015 at 02:00:53PM +0100, Lutz Vieweg wrote:
> On 02/06/2015 06:20 AM, Qu Wenruo wrote:
> > From: Lutz Vieweg
> >> use case: You have two huge files on a btrfs, you assume they contain the
> >> same bytes,
> >> but you do not know for sure.
> >>
> >> Is there a way to get a checks
My laptop has two disks, a SSD and a traditional magnetic disk. I plan
to make a partition on the mag disk equal in size the SSD and set up
BTRFS RAID1. This I know how to do.
The only reason I'm doing the RAID1 is for the self-healing. I realize
writing large amounts of data will be slower than t
Hi Linus,
Forrest Liu tracked down a missing blk_finish_plug in the btrfs logging
code. This isn't a new bug, and it's hard to hit. But, it's safe enough
for inclusion now, and in my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
I missed the cc:
We can have two concurrent fsync operations against the same file,
in which case both fsyncs can collect and process the same ordered
This allows for a time window where a race can lead to those ordered
extents never getting their reference count decremented to 0, leading
to memory leaks, getting r
On Sun, Feb 01, 2015 at 11:51:19PM +0300, Dan Carpenter wrote:
> Hello Mark Fasheh,
>
> The patch 1152651a0817: "btrfs: qgroup: account shared subtrees
> during snapshot delete" from Jul 17, 2014, leads to the following
> static checker warning:
What checker are you using?
> fs/btrfs/exte
So what I don't understand which process created the sub volumes. I fear if
I start again it will be the same. The OpenSuse YAST2 Partition tool does
not show any subvolumes.
Thank you
Markus
"Chris Murphy" wrote in message
news:CAJCQCtRHsiau97r66O9PC6O0mK7Yafc3aE2HX=4bt-w4nw8...@mail.gmail
On Fri, Feb 6, 2015 at 3:29 PM, Markus Moeller wrote:
> So what I don't understand which process created the sub volumes.
Yast had to have done it. It did all the partitioning, creation of the
file system, and it created fstab.
> I fear if
> I start again it will be the same.
Don't check the L
On Fri, Feb 6, 2015 at 1:01 PM, Brian B wrote:
> My laptop has two disks, a SSD and a traditional magnetic disk. I plan
> to make a partition on the mag disk equal in size the SSD and set up
> BTRFS RAID1. This I know how to do.
There isn't a write mostly option in btrfs like there is with md rai
Brian B posted on Fri, 06 Feb 2015 15:01:30 -0500 as excerpted:
> The only reason I'm doing the [btrfs] RAID1 is for the self-healing. I
> realize writing large amounts of data will be slower than the SSD
> alone, but is it possible to set it up to only read from the magnetic
> drive if there's an
20 matches
Mail list logo
