On 28/8/2014 8:04 μμ, Jean-Denis Girard wrote:
Hi Chris,
Thanks for your detailed answer.
Le 28/08/2014 06:25, Chris Murphy a écrit :
9. btrfs-find-root /dev/sdc
Super think's the tree root is at 29917184, chunk root 20987904
Well block 4194304 seems great, but generation doesn't match,
While under random IO, a block group's free space cache eventually reaches
a state where it has a mix of extent entries and bitmap entries representing
free space regions.
As later free space regions are returned to the cache, some of them are merged
with existing extent entries if they are
After the commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8 (titled
mm/msync.c: sync only the requested range in msync()), our fsync
callback can be called with a range that covers only part of the
file and not the whole file anymore. Under certain circumstances
this leads to crashes that produce
On Wed, Aug 27, 2014 at 11:16:03AM -0700, Zach Brown wrote:
Seems like this is already leaking a refcount and only returns 0.. so
maybe remove the bug_on something like this totally untested patch?
Looks much better than my patch, I'm taking it.
There's another #if 0-ed out caller in
On Thu, Aug 28, 2014 at 10:25:55AM +0800, Gui Hecheng wrote:
The printf of @offset enlightens the user little.
And the restore cmd is not a debugging tool, so just
remove the debug-info-like printf.
I'd like to let the restore command be more verbose as it's potentially
working with a broken
On Fri, Aug 29, 2014 at 01:37:48PM +0100, Filipe Manana wrote:
After the commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8 (titled
mm/msync.c: sync only the requested range in msync()), our fsync
callback can be called with a range that covers only part of the
file and not the whole file
Hi, this is David Wu from Shanghai, China.
We are a printing company, we can print color box, corrugated box,
label, hang tag etc.
Please let me know if you need these.
I will send you the website then.
Best regards,
David Wu
--
To unsubscribe from this list: send the line unsubscribe
On 08/29/2014 10:51 AM, Christoph Hellwig wrote:
On Fri, Aug 29, 2014 at 01:37:48PM +0100, Filipe Manana wrote:
After the commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8 (titled
mm/msync.c: sync only the requested range in msync()), our fsync
callback can be called with a range that covers
On 8/17/14, Shriramana Sharma samj...@gmail.com wrote:
Hello. One more Q re generic BTRFS behaviour.
https://btrfs.wiki.kernel.org/index.php/Main_Page specifically
advertises BTRFS's Space-efficient packing of small files.
Hello. I realized that while I got lots of interesting advice on how
to
On Fri, Aug 29, 2014 at 09:34:54PM +0530, Shriramana Sharma wrote:
On 8/17/14, Shriramana Sharma samj...@gmail.com wrote:
Hello. One more Q re generic BTRFS behaviour.
https://btrfs.wiki.kernel.org/index.php/Main_Page specifically
advertises BTRFS's Space-efficient packing of small files.
On 07/29/2014 05:24 AM, Miao Xie wrote:
This patch implement data repair function when direct read fails.
The detail of the implementation is:
- When we find the data is not right, we try to read the data from the other
mirror.
- After we get right data, we write it back to the corrupted
On Fri, Aug 29, 2014 at 3:51 PM, Christoph Hellwig h...@infradead.org wrote:
On Fri, Aug 29, 2014 at 01:37:48PM +0100, Filipe Manana wrote:
After the commit 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8 (titled
mm/msync.c: sync only the requested range in msync()), our fsync
callback can be called
On Fri, Aug 29, 2014 at 07:52:33PM +0100, Filipe David Manana wrote:
Point taken Christoph, this isn't specific to msync nor impossible to
happen before 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8.
I'll update the commit log to reflect that.
Thanks for looking.
Btw, if you have an easy enough
While doing a ranged fsync, that is, one whose range doesn't cover the
whole possible file range (0 to LLONG_MAX), we can crash under certain
circumstances with a trace like the following:
[41074.641913] invalid opcode: [#1] SMP DEBUG_PAGEALLOC
(...)
[41074.642692] CPU: 0 PID: 24580 Comm:
On Fri, Aug 29, 2014 at 7:55 PM, Christoph Hellwig h...@infradead.org wrote:
On Fri, Aug 29, 2014 at 07:52:33PM +0100, Filipe David Manana wrote:
Point taken Christoph, this isn't specific to msync nor impossible to
happen before 7fc34a62ca4434a79c68e23e70ed26111b7a4cf8.
I'll update the commit
At as 32 bit KVM I run these 2 commands:
tfoerste@n22kvm ~ $ mkdir /mnt/ramdisk/btrfs; truncate -s 97M
/mnt/ramdisk/btrfs.fs; /sbin/mkfs.btrfs /mnt/ramdisk/btrfs.fs; sudo su -c
mount -o loop,compress=lzo /mnt/ramdisk/btrfs.fs /mnt/ramdisk/btrfs; chmod 777
/mnt/ramdisk/btrfs
tfoerste@n22kvm ~
16 matches
Mail list logo
