On 05/09/2013 01:13, Zhi Yong Wu wrote:
HI, all
I saw that bcache will be merged into kernel upstream soon, so i
want to know if btrfs hot relocation support is still meanful, if no,
i will not continue to work on it. can anyone let me know this?
thanks.
Which one is better?
Please do
btrfs maintainer's opinion is very important, i guess.
On Thu, May 9, 2013 at 2:30 PM, Stefan Behrens
sbehr...@giantdisaster.de wrote:
On 05/09/2013 01:13, Zhi Yong Wu wrote:
HI, all
I saw that bcache will be merged into kernel upstream soon, so i
want to know if btrfs hot relocation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/05/13 16:13, Zhi Yong Wu wrote:
i want to know if btrfs hot relocation support is still meanful
It is to me. The problem with bcache is that it is a cache. ie if you
have a 256GB SSD and a 500GB HDD then you'll have total storage of 500GB.
On 05/09/2013 08:42, Zhi Yong Wu wrote:
btrfs maintainer's opinion is very important, i guess.
My opinion is not important and I shall shut up?
On Thu, May 9, 2013 at 2:30 PM, Stefan Behrens
sbehr...@giantdisaster.de wrote:
On 05/09/2013 01:13, Zhi Yong Wu wrote:
HI, all
I saw that
I'm just curious why the last of the following 3 commands :
$ dd if=/dev/zero of=/mnt/ramdisk/disk1 bs=1M count=257
$ yes | /sbin/mkfs.btrfs /mnt/ramdisk/disk1
$ mount -o loop /mnt/ramdisk/disk1 /mnt/t
gives 3x the same log message :
2013-05-09T11:23:00.230+02:00 n22 kernel: device fsid
On Thu, May 09, 2013 at 11:26:25AM +0200, Toralf Förster wrote:
I'm just curious why the last of the following 3 commands :
$ dd if=/dev/zero of=/mnt/ramdisk/disk1 bs=1M count=257
$ yes | /sbin/mkfs.btrfs /mnt/ramdisk/disk1
$ mount -o loop /mnt/ramdisk/disk1 /mnt/t
gives 3x the same log
Dear Devs,
This is more a use case question of what is a good idea to do...
Can btrfs support snapshots of the filesystem at very regular intervals,
say minute by minute or even second by second?
Or are there limits that will be hit with metadata overheads or
links/reference limits or CPU
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/09/2013 12:04 PM, Hugo Mills wrote:
At a guess, two of those are probably from btrfs dev scan
triggered by udev.
Those messages do only appear for a btrfs, not if I choose ext4.
- --
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4
I can only speak from experience, a snapshot can take up to a minute
to create later on, so minutely snapshots are out of the question
then... I have snapshots every hour and I have no problems with that
at all :)
On Thu, May 9, 2013 at 12:10 PM, Martin m_bt...@ml1.co.uk wrote:
Dear Devs,
This
On Thu, May 09, 2013 at 12:37:38PM +0200, Toralf Förster wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/09/2013 12:04 PM, Hugo Mills wrote:
At a guess, two of those are probably from btrfs dev scan
triggered by udev.
Those messages do only appear for a btrfs, not if I choose
Hi,
I just try your steps, but only 1x log message.
Anyway, i use the latest btrfs-progs.
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
Can you try this and see if it happens again?
Thanks,
Wang
I'm just curious why the last of the following 3 commands :
$ dd
Oh, My kernel version is btrfs-next.
This message gets from kernel..so you can try this url:
git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
Hi,
I just try your steps, but only 1x log message.
Anyway, i use the latest btrfs-progs.
Hello Josef Bacik,
This is a semi-automatic email about new static checker warnings.
The patch fd8b2b611580: Btrfs: cleanup destroy_marked_extents from
Apr 24, 2013, leads to the following Smatch complaint:
fs/btrfs/disk-io.c:3814 btrfs_destroy_marked_extents()
warn: variable
On Thu, May 09, 2013 at 06:22:06AM -0600, Dan Carpenter wrote:
Hello Josef Bacik,
This is a semi-automatic email about new static checker warnings.
The patch fd8b2b611580: Btrfs: cleanup destroy_marked_extents from
Apr 24, 2013, leads to the following Smatch complaint:
On 05/09/2013 01:47 PM, Wang Shilong wrote:
Anyway, i use the latest btrfs-progs.
well, under Gentoo I used sys-fs/btrfs-progs- which points always to the
latest git version :
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
My host kernel is stable 3.9.1
The mount
On Thu, May 09, 2013 at 02:45:00PM +0200, Toralf Förster wrote:
On 05/09/2013 01:47 PM, Wang Shilong wrote:
Anyway, i use the latest btrfs-progs.
well, under Gentoo I used sys-fs/btrfs-progs- which points always to the
latest git version :
I hit this while working on fsck, I got some weird corruption where the number
of items was way higher than what would fit in a leaf, which would make things
blow up. This fixes the problem by catching it and returning an error so we
gracefully exit instead of segfaulting. Thanks,
An unfortunate side effect to my fsync bug means that anybody who didn't hit the
BUG_ON() during tree log replay would have ended up with a corrupted file
system. Currently our fsck does not catch this because it just looks for
bytenrs for backrefs, it doesn't look at the num_bytes at all. So
kernel: 3.9.0
btrfs-progs: pulled from git this morning
Trying to receive a 5gig send file. the first bit is fast, doing 10 - 50MB/sec.
then it slows down. cpu usage is 50% (dual core machine).
when i do a strace, it looks like this, repeating over an over, about 1 piece
each second:
--
read(3,
Chris hit a bug where we weren't finding extent records when running extent ops.
This is because we use the delayed_ref_head when running the extent op, which
means we can't use the -type checks to see if we are metadata. We also lose
the level of the metadata we are working on. So to fix this
Chris hit a bug where we weren't finding extent records when running extent ops.
This is because we use the delayed_ref_head when running the extent op, which
means we can't use the -type checks to see if we are metadata. We also lose
the level of the metadata we are working on. So to fix this
Hi Linus,
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
These are mostly fixes. The biggest exceptions are Josef's skinny
extents and Jan Schmidt's code to rebuild our quota indexes if they get
out of sync (or you enable quotas
I'll preface that I'm running Ubuntu 13.04 with the standard 3.8 series
kernel so please disregard if this has been fixed in higher versions. This
is on a btrfs RAID1 with 3 then 4 disks.
My use case is to set the nocow 'C' flag on a directory and copy in some
files, then make lots of writes
We want this for btrfs_extent_same. Basically readpage and friends do their
own extent locking but for the purposes of dedupe, we want to have both
files locked down across a set of readpage operations (so that we can
compare data). Introduce this variant and a flag which can be set for
On Thu, May 09, 2013 at 03:41:49PM -0500, Kyle Gates wrote:
I'll preface that I'm running Ubuntu 13.04 with the standard 3.8
series kernel so please disregard if this has been fixed in higher
versions. This is on a btrfs RAID1 with 3 then 4 disks.
My use case is to set the nocow 'C' flag on
25 matches
Mail list logo
