When there are files that have parts shared with snapshots, the
restore command was incorrectly restoring them, as it was not
taking into account the offset and number of bytes fields from
the file extent item. Besides leaving the recovered file corrupt,
it was also inneficient as it read and
Linux Plumbers has approved a file and storage microconference. The overview
page is here:
http://wiki.linuxplumbersconf.org/2013:file_and_storage_systems
I would like to started gathering in ideas for topics. I have been approached
already with a request to cover the copy_range work Zach
Can we have a discussion on Lustre client in the kernel? Thanks
./Sorin
-Original Message-
From: linux-fsdevel-ow...@vger.kernel.org
[mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of Ric Wheeler
Sent: Friday, July 12, 2013 1:21 PM
To: linux-s...@vger.kernel.org; Linux FS Devel;
On Thu, Jul 11, 2013 at 10:31:22AM -0400, Chris Mason wrote:
Do you have benchmark numbers for how much these help? I hesitate to
bring in the likely/unlikely unless we can see it on the benchmarks.
Seconded, I doubt that this particular function gets any measurable
speed improvement with the
I've enabled extended inode refs and skinny metadata extent refs with
btrfstune.
Then, I've tried running btrfs filesystem balance - unfortunately it
segfaulted.
(not sure if I should run balance operation after using btrfstune with -r and
-x)?
This is with 3.10 kernel with Btrfs: make
