Jeff,
Nice patch. However its better if we do this in the btrfs kernel
function btrfs_scan_one_device(). Since the non-canonicalize path
can still sneak through the btrfs specific mount option "device=".
Any comments ?
Thanks, Anand
On 06/05/2014 04:43 AM, Jeff Mahoney wrote:
mount(8)
From: Eric Sandeen
If we didn't find what we are looking for in /proc/partitions,
we're not going to find it by scanning every node under /dev, either.
But that's just what btrfs_scan_for_fsid() does.
Remove that fallback; at that point btrfs_scan_for_fsid() just calls
scan_for_btrfs(), so remo
From: Eric Sandeen
We can scan for btrfs devices in a few ways. By default
libblkid is used for "device scan" and "filesystem show";
with the -m option only mounted filesystems are scanned,
and with -d we physically read every system device.
But there's no reason for the complexity of a descent
With the changes as in the previous patch, now scan_for_btrfs()
is an unused function. So delete it.
Signed-off-by: Anand Jain
---
utils.c | 15 ---
utils.h | 1 -
2 files changed, 16 deletions(-)
diff --git a/utils.c b/utils.c
index 7c1e48b..38d867d 100644
--- a/utils.c
+++ b/util
The libblkid scan method which was introduced later, will also
scan devices under /proc/partitions. So we don't have to do
the explicit scan of the same.
Remove the scan method BTRFS_SCAN_PROC.
Signed-off-by: Anand Jain
---
cmds-device.c | 5 ++---
cmds-filesystem.c | 10 +-
disk-i
From: Eric Sandeen
After the previous 2 patches, nothing uses
whole-dev-tree scanning, so remove the code which
implemented that functionality.
Signed-off-by: Eric Sandeen
Reviewed-by: Anand Jain
---
utils.c | 114
utils.h | 6
On 09/01/2014 03:41 PM, Liu Bo wrote:
> I believe that this warning of btrfs_evict_inode also comes from a result of
> lseek, and Chris said that he's prepared a fix for that, so it's queued in the
> next version.
>
> thanks,
> -liubo
So rather fixed in -rc6 because v3.17-rc4-337-gfc486b0 still s
Hello,
Kernel being 3.16.2-1-ARCH
I had the following kernel bug while running "btrfs balance /" without further
arguments on my laptop (the command ended in "segmentation fault").
(Another question would be : why does the "btrfs balance" command hold the
terminal when the work itself seems to
On Sat, 13 Sep 2014 13:36:37 +0800
Anand Jain wrote:
> Xavier, Johannes,
>
> The quickest workaround for you will be to try to match
> the device path as in the btrfs fi show -m output to
> your probably fstab/mnttab entry.
Doesn't work here. I don't even get a path with the affected
On Sat, 13 Sep 2014 19:55:25 +0200
Johannes Hirte wrote:
> On Sat, 13 Sep 2014 13:36:37 +0800
> Anand Jain wrote:
>
> > Xavier, Johannes,
> >
> > The quickest workaround for you will be to try to match
> > the device path as in the btrfs fi show -m output to
> > your probably fstab/m
Johannes Hirte posted on Sat, 13 Sep 2014 23:23:20 +0200 as excerpted:
> On Sat, 13 Sep 2014 19:55:25 +0200 Johannes Hirte
> wrote:
>
>> On Sat, 13 Sep 2014 13:36:37 +0800 Anand Jain
>> wrote:
>>
>>> The quickest workaround for you will be to try to match
>>> the device path as in the btrfs fi
On 12.09.2014 12:47, Hugo Mills wrote:
I've done this before, by accident (pulled the wrong drive, reinserted
it). You can fix it by running a scrub on the device (btrfs scrub
start /dev/ice, I think).
I'd like to remind everyone that btrfs has weak checksums. It may be
good for correcting an
On Sun, Sep 14, 2014 at 05:15:08AM +0200, Piotr Pawłow wrote:
> On 12.09.2014 12:47, Hugo Mills wrote:
> >I've done this before, by accident (pulled the wrong drive, reinserted
> >it). You can fix it by running a scrub on the device (btrfs scrub
> >start /dev/ice, I think).
>
> I'd like to remind
Hi Josef,
> One problem that has plagued us is that a user will use up all of his space
> with
> data, remove a bunch of that data, and then try to create a bunch of small
> files
> and run out of space. This happens because all the chunks were allocated for
> data since the metadata requiremen
14 matches
Mail list logo
