On Mon, Jul 01, 2013 at 08:54:35AM -0400, Josef Bacik wrote:
> On Tue, Jun 04, 2013 at 06:17:54PM -0400, Zach Brown wrote:
> >
> > I finally sat down to fix that readdir hang that has been in the back
> > of my mind for a while. I *hope* that the fix is pretty simple: just
> > don't manufacture a
On Wed, Jul 10, 2013 at 10:45:45AM -0700, Mark Fasheh wrote:
> On Wed, Jul 10, 2013 at 09:31:05AM -0700, Mark Fasheh wrote:
> > As far as I can tell we'll be carrying this patch until a better
> > solution is possible.
> >
> > When that will happen, I don't know.
> > --Mark
>
> Well, what do
Commit 8d082fb727ac11930ea20bf1612e334ea7c2b697 (Btrfs: do not mount when
we have a sectorsize unequal to PAGE_SIZE) requires the sectorsize to be
equal to the pagesize for the filesystem to be mountable.
The nodesize and leafsize should be equal, and not larger than 65536.
Adding this informatio
On Thu, Jul 11, 2013 at 01:25:39PM +0800, Miao Xie wrote:
> It is unnecessary to unlock the extent by the page size, we can do it
> in batches, it makes the random read be faster by ~6%.
>
> Signed-off-by: Miao Xie
> ---
> fs/btrfs/extent_io.c | 70
> ++--
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 wrote
Quoting David Sterba (2013-07-10 18:54:54)
> On Sun, Jun 30, 2013 at 12:35:09PM -0500, Mitch Harder wrote:
> > There's been a parallel effort to incorporate a general set of lz4
> > patches in the kernel.
> >
> > I see these patches are currently queued up in the linux-next tree, so
> > we may see
I noticed while running multi-threaded fsync tests that sometimes fsck would
complain about an improper gap. This happens because we fail to add a hole
extent to the file, which was happening when we'd split a hole EM because
btrfs_drop_extent_cache was just discarding the whole em instead of spli
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.
(The patch does look fine though)
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.
Quoting Miao Xie (2013-07-11 01:25:38)
> Before applying this patch, we cached the csum value into the extent state
> tree when reading some data from the disk, this operation increased the lock
> contention of the state tree.
>
> Now, we just store the csum value into the bio structure or other u
The log message level 'critical' is verbose enough, 'emergency' beeps on
all terminals.
Signed-off-by: David Sterba
---
fs/btrfs/volumes.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index b2d1eac..1fd7b5d 100644
--- a/fs/bt
So to cache free space, we iterate every extent item to gather free space info.
When we have say 10,000 non-inline extent refs(such as BTRFS_EXTENT_DATA_REF),
it takes quite a long time, and since inline extent refs and non-inline ones
have
same objectid in their keys, we can just re-search the t
There are only 4 patches in this patchset, not 5.
Sorry for my mistake.
Miao
On thu, 11 Jul 2013 13:25:36 +0800, Miao Xie wrote:
> Signed-off-by: Miao Xie
> ---
> fs/btrfs/extent_io.c | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/fs/btrfs/
12 matches
Mail list logo
