I tried this once before and it didn't work and now I tried it again and
it still didn't work. But then I became a bit suspicious of WHY it was
not working. I used a number of different delay intervals and carefully
compared them with each other and with no delay specified in the system
logs
If a device could not be opened in volumes.c:read_one_dev(), a
btrfs_device instance was allocated and added to the list of
devices of the fs - however this device instance had its fd,
name and label fields not initialized. This is problematic in
disk-io.c:close_all_devices() as it tried to sync, f
On Tue, Jun 04, 2013 at 04:26:57PM -0700, Zach Brown wrote:
> On Tue, Jun 04, 2013 at 07:16:53PM -0400, Chris Mason wrote:
> > Quoting Zach Brown (2013-06-04 18:17:54)
> > > Hi gang,
> > >
> > > I finally sat down to fix that readdir hang that has been in the back
> > > of my mind for a while. I
I hit a hang when run_delayed_refs returned an error in the beginning of
btrfs_commit_transaction. If we decide we need to commit the transaction in
btrfs_end_transaction we'll set BLOCKED and start to commit, but if we get an
error this early on we'll just exit without committing. This is fine,
On Mon, Jun 10, 2013 at 10:59:15PM +0800, Anand Jain wrote:
> This adds two ioctl BTRFS_IOC_GET_FSIDS and BTRFS_IOC_GET_DEVS
> which reads the btrfs_fs_devices and btrfs_device structure
> from the kernel respectively.
Why not just use sysfs to export the device lists?
> The information in these
If a device could not be opened in volumes.c:read_one_dev(), a
btrfs_device instance was allocated and added to the list of
devices of the fs - however this device instance had its fd,
name and label fields not initialized. This is problematic in
disk-io.c:close_all_devices() as it tries to close t
On 6/10/13 9:56 AM, Anand Jain wrote:
> btrfs_scan_for_fsid uses only one argument run_ioctl out of 3
> so remove the rest two of them
and run_ioctl is only ever '1' (and it's completely unobvious
at the call point what '1' means).
Why not just go with 0 args?
Then only btrfs_scan_one_dir and bt
After finding a super block in a device also validate its
checksum. This validation is done in the kernel but it was
missing in btrfs-progs.
The function btrfs_check_super_csum() is imported from the
file fs/btrfs/disk-io.c in the kernel source tree.
Signed-off-by: Filipe David Borba Manana
---
Signed-off-by: Filipe David Borba Manana
---
btrfs-debug-tree.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/btrfs-debug-tree.c b/btrfs-debug-tree.c
index 97459b1..74d4d66 100644
--- a/btrfs-debug-tree.c
+++ b/btrfs-debug-tree.c
@@ -195,10 +195,10 @@ int main(i
If a device could not be opened in volumes.c:read_one_dev(), a
btrfs_device instance was allocated and added to the list of
devices of the fs - however this device instance had its fd,
name and label fields not initialized. This is problematic in
disk-io.c:close_all_devices() as it tries to close t
Some fixes and minor enhancements.
Filipe David Borba Manana (5):
Btrfs-progs: fix closing of devices
Btrfs-progs: Add missing free_extent_buffer() call to debug-tree
Btrfs-progs: Add missing close_ctree() calls to debug-tree
Btrfs-progs: pretty print dir_item type
Btrfs-progs: Validate
Instead of printing an integer, print a symbolic name which
is more human friendly. Particularly useful when using the
program btrfs-debug-tree.
Signed-off-by: Filipe David Borba Manana
---
print-tree.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion
Signed-off-by: Filipe David Borba Manana
---
btrfs-debug-tree.c |1 +
1 file changed, 1 insertion(+)
diff --git a/btrfs-debug-tree.c b/btrfs-debug-tree.c
index bae7f94..97459b1 100644
--- a/btrfs-debug-tree.c
+++ b/btrfs-debug-tree.c
@@ -355,6 +355,7 @@ again:
On Mon, Jun 10, 2013 at 08:59:15AM -0600, Anand Jain wrote:
> This adds two ioctl BTRFS_IOC_GET_FSIDS and BTRFS_IOC_GET_DEVS
> which reads the btrfs_fs_devices and btrfs_device structure
> from the kernel respectively.
>
> The information in these structure are useful to report the
> device/fs inf
On Monday, June 10, 2013 09:00:47 AM Josef Bacik wrote:
> On Sat, Jun 08, 2013 at 01:14:35PM -0600, Thomas Koch wrote:
> > Hi,
> >
> > I had a power loss on my btrfs file system during package installation and
> > now I found this:
> >
> >
> > % ls -l /var/lib/dpkg/tmp.ci
> > ls: cannot access /
I hit a deadlock because we aborted when flushing delayed refs but didn't wake
any of the other flushers up and so everybody was just sleeping forever. This
should fix the problem. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/extent-tree.c |1 +
1 files changed, 1 insertions(+), 0 delet
Consider the following environment. We have a storage array that
provides its own facilities for creating snapshots, replicas, and
clones. We create a Btrfs file system on a volume on one of these
storage arrays, and we mount a snapshot of that volume on the same
host. (The simple use-ca
Anand Jain (2):
btrfs: device delete to get errors from the kernel
btrfs: add framework to read fs info and dev info from the kernel
fs/btrfs/ioctl.c | 22
fs/btrfs/super.c | 100 +---
fs/btrfs/volumes.c | 125
This adds two ioctl BTRFS_IOC_GET_FSIDS and BTRFS_IOC_GET_DEVS
which reads the btrfs_fs_devices and btrfs_device structure
from the kernel respectively.
The information in these structure are useful to report the
device/fs information in line with the kernel operations and
thus immediately address
when user runs command btrfs dev del the raid requisite error if any
goes to the /var/log/messages, its not good idea to clutter messages
with these user (knowledge) errors, further user don't have to review
the system messages to know problem with the cli it should be dropped
to the user as part o
the btrfs device scan usage does not publish --all-devices
option so add it
Signed-off-by: Anand Jain
---
cmds-device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmds-device.c b/cmds-device.c
index 41e79d3..d25159b 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -178,
when user runs command btrfs dev del the raid requisite error if any
goes to the /var/log/messages, its not good idea to clutter messages
with these user (knowledge) errors, further user don't have to review
the system messages to know problem with the cli it should be dropped
to the user as part o
As of now btrfs filesystem show reads directly from
disks. So sometimes output can be stale, mainly when
user want to verify their latest operation like,
labeling or device delete or add... etc.
This patch adds --kernel option to the 'filesystem show'
subcli, which will read from the kernel instea
appears to be a cut and paste error
Signed-off-by: Anand Jain
---
cmds-filesystem.c | 2 +-
man/btrfs.8.in| 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-filesystem.c
index f41a72a..c6a7100 100644
--- a/cmds-filesystem.c
+++ b/cmds-filesy
This would help to reuse the function
Signed-off-by: Anand Jain
---
utils.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/utils.c b/utils.c
index f9545b8..b205005 100644
--- a/utils.c
+++ b/utils.c
@@ -1313,7 +1313,7 @@ static int get_label_unmounted(con
Currently, btrsf fi show and btrfs dev scan uses
/proc/partitions (by default) (which gives priority
to dm- over sd paths) and with --all-devices it
will scan /dev only (when it skips links under /dev/mapper).
However using /dev/mapper paths are in common practice
with mount, fstab, and lvm, so it
we would need btrfs_scan_one_dir to san devs under /dev/mapper,
but /dev/mapper has links to the actual devs and current implementation
of btrfs_scan_one_dir skips links so it does not pick any
links under /dev/mapper. skipping links is fine when scanning whole of
/dev. But when we just want to sca
the dev scan to find btrfs is performed at two locations
all most the same way one at filesystem show and another
at device scan. They both follow the same steps. This
patch does not alter anything except that it brings these
two same logic into the function scan_for_btrfs so that
we can play tweak
A patch set revised/rebased on integration-20130524
these were posted before but havn't made into the repo yet.
I.
Introduce btrfs filesystem show --kernel
There are bugs surrounding btrfs filesystem show,
when ran immediately after the oprations like
btrfs fi label and btrfs dev delete
the bt
btrfs_scan_for_fsid uses only one argument run_ioctl out of 3
so remove the rest two of them
Signed-off-by: Anand Jain
---
btrfs-find-root.c | 2 +-
disk-io.c | 2 +-
utils.c | 5 ++---
utils.h | 3 +--
4 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/bt
On Sat, Jun 08, 2013 at 01:14:35PM -0600, Thomas Koch wrote:
> Hi,
>
> I had a power loss on my btrfs file system during package installation and
> now
> I found this:
>
>
> % ls -l /var/lib/dpkg/tmp.ci
> ls: cannot access /var/lib/dpkg/tmp.ci/conffiles: Stale NFS file handle
> ls: cannot acce
A user reported scrub taking up an unreasonable amount of ram as it ran. This
is because we lookup the csums for the extent we're scrubbing but don't free it
up until after we're done with the scrub, which means we can take up a whole lot
of ram. This patch fixes this by dropping the csums once w
Quoting Mitch Harder (2013-06-10 00:03:31)
> I'm running into a problem with the btrfs-cleaner thread becoming
> blocked on xfstests 068.
>
> The test locks up indefinitely without completing (normally it
> finished in about 45 seconds on my test box).
>
> I've replicated the issue on 3.10.0_rc5
Hello,
> On 10.06.2013 08:21, Tomasz Chmielewski wrote:
>> I'm trying to use btrfs quotas, but I'm unable to find reliable
>> documentation on its usage.
>>
>> Let's start with an empty subvolume:
>>
>> - assign 200 MB space to it:
>>
>> # btrfs qgroup limit 200m /mnt/btrfs-backup/tester/
>>
>
Hi Chris,
I know, Linus is turning grumpy again. I'd still feel better if we sent this
patch set for the very next rc now. Any particular objections?
-Jan
On Tue, May 28, 2013 at 17:47 (+0200), Jan Schmidt wrote:
> Here are three fixes for the new qgroup rescan feature. The first two
> are quite
On Mon, 10 Jun 2013 09:41:39 +0200
Arne Jansen wrote:
> > Now, my questions:
> >
> > - what do both 104882176 104882176 numbers represent?
>
> The first number represents the amount of data in that subvolume,
> regardless whether that data is shared with other subvolumes or
> not.
> The second
On 10.06.2013 08:21, Tomasz Chmielewski wrote:
> I'm trying to use btrfs quotas, but I'm unable to find reliable
> documentation on its usage.
>
> Let's start with an empty subvolume:
>
> - assign 200 MB space to it:
>
> # btrfs qgroup limit 200m /mnt/btrfs-backup/tester/
>
>
> - see the usage
37 matches
Mail list logo