Re: IOCTL #21 part two: btrfs progs patch, including iso 8601 timeout support
On Wednesday, 06 October, 2010, David Nicol wrote:
the ISO 8601 duration support is very loose, but I believe it is
accurate for valid
input. Without any non-numeric designators, the timeout is interpreted
as seconds,
so
btrfs fi reclaim 10.3321 /my_btrfs_mount || echo timed out
will wait 10332 ms before echoing, if the pending subvolume deletions
take longer than that.
Timeout defaults to 0, and path defaults to current directory.
Please the next time put your patch inline or it is more difficult to
highlight a suggestion.
Any way:
1)
[...]
+ { do_wait4clean, 1002, /* require at most two args */
+ filesystem reclaim, path [timeout]\n
+ Wait for cleanup of deleted subvolumes in the filesystem
path.\n
+ Optional timeout in whole or partial seconds, or ISO8601
string.\n
+ },
[...]
+int do_wait4clean(int argc, char **argv)
+{
+ int fd, res;
+struct btrfs_ioctl_cleaner_wait_args w4c_arg;
+
+ char*path = .;
+w4c_arg.ms = 0UL;
+
+if (argc 1)
+path = argv[1];
+if (argc 2)
+ w4c_arg.ms = iso8601toms(argv[2]);
In the man page and in the help the syntax is reported as:
btrfs filesystem reclaim path [timeout]
instead it should be
btrfs filesystem reclaim [path [timeout]]
and it has to be reported that path is optional and if it is omitted the
current CWD is taken.
2) I think that it is more reasonable avoid a strict iso 8601 syntax for the
time. I suggest to use a simple syntax like
0. - subsecond
s or nothing - seconds
m - minutes
h - hour
d - day
M - month (but make sense to wait up to a month ?)
[...]
3) As minor issue I have to point out that reclaim seems (to me) that the
user has to start this command in order to obtain more space, like if this
command starts a garbage collector. In any case the help/man page explain
clearly the behavior of the command.
4)
[...]
+unsigned long iso8601toms(char *P){
+unsigned long ms;
+double component;
+char *ptr;
+char *endptr;
+short M_min = 0;
+
+ms = 0UL;
+ptr = P;
+for(;;){
+ component=strtod(ptr, endptr);
+ switch (*endptr)
+ {
+ case 'P': /* anchor */ case 'p':
+ if (ptr P)
+fprintf(stderr, ignoring non-initial P
+ in ISO8601 duration string %s\n, P);
+ break;
+ case 'Y': /* years */ case 'y':
+ component *= 12;
+ BIGM:
+ /* average days in a gregorian month */
+ component *= (365.2425 / 12.0);
+ /* ms in a day */
+ component *= ( 24 * 3600 * 1000 );
+ ms += component;
+ break;
+ case 'T': /* Time (not date) anchor */ case 't':
+ M_min = 1;
+ break;
+ case 'W': /* week */ case 'w':
+ component *= 7;
+ case 'D': /* day */ case 'd':
+ component *= 24 ;
+ case 'H': /* hour */ case 'h':
+ component *= 60;
+ M_min = 1;
+ case 'M': /* month, or minute */ case 'm':
+ if (!M_min++)
+ goto BIGM;
+ component *= 60;
[...]
In the function I suggest to avoid if possible a goto in a switch case. I
think that it is more clear to repeat few lines instead of doing a goto.
Reagrds
G.Baroncelli
--
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it
Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: add support for mixed data+metadata block groups V2
On Wed, 2010-10-06 at 16:21 -0400, Josef Bacik wrote:
There are just a few things that need to be fixed in the kernel to support
mixed
data+metadata block groups. Mostly we just need to make sure that if we are
using mixed block groups that we continue to allocate mixed block groups as we
need them. Also we need to make sure __find_space_info will find our space
info
if we search for DATA or METADATA only. Tested this with xfstests and it
works
nicely. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
V1-V2: In do_chunk_alloc I was changing flags to == space_info-flags, which
isn't right since space_info doesn't carry the RAID profiles anymore, so
instead
check to see if the space info has DATA and METADATA set and if so set that in
the flags as well.
fs/btrfs/extent-tree.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 91a0a41..27eddb3 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -547,7 +547,7 @@ static struct btrfs_space_info *__find_space_info(struct
btrfs_fs_info *info,
rcu_read_lock();
list_for_each_entry_rcu(found, head, list) {
- if (found-flags == flags) {
+ if (found-flags flags) {
rcu_read_unlock();
return found;
}
@@ -3267,6 +3267,15 @@ static int do_chunk_alloc(struct btrfs_trans_handle
*trans,
spin_unlock(space_info-lock);
/*
+ * If we have mixed data/metadata chunks we want to make sure we keep
+ * allocating mixed chunks instead of individual chunks.
+ */
+ if ((space_info-flags (BTRFS_BLOCK_GROUP_DATA |
+ BTRFS_BLOCK_GROUP_METADATA)) ==
+ (BTRFS_BLOCK_GROUP_DATA | BTRFS_BLOCK_GROUP_METADATA))
+ flags |= (BTRFS_BLOCK_GROUP_DATA | BTRFS_BLOCK_GROUP_METADATA);
This sort of construct appears a few times.
Personally, I prefer a macroish (read 'inline function') construct,
perhaps with a longish name if needed, than multiple line breaks within
a logical expression. IMHO, having multiple line breaks makes the code
somewhat harder to read.
+
+ /*
* if we're doing a data chunk, go ahead and make sure that
* we keep a reasonable number of metadata chunks allocated in the
* FS as well.
@@ -4793,6 +4802,7 @@ static noinline int find_free_extent(struct
btrfs_trans_handle *trans,
bool found_uncached_bg = false;
bool failed_cluster_refill = false;
bool failed_alloc = false;
+ bool use_cluster = true;
u64 ideal_cache_percent = 0;
u64 ideal_cache_offset = 0;
@@ -4807,16 +4817,26 @@ static noinline int find_free_extent(struct
btrfs_trans_handle *trans,
return -ENOSPC;
}
+ /*
+ * If the space info is for both data and metadata it means we have a
+ * small filesystem and we can't use the clustering stuff.
+ */
+ if ((space_info-flags (BTRFS_BLOCK_GROUP_METADATA |
+ BTRFS_BLOCK_GROUP_DATA)) ==
+((BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA)))
+ use_cluster = false;
+
if (orig_root-ref_cows || empty_size)
allowed_chunk_alloc = 1;
- if (data BTRFS_BLOCK_GROUP_METADATA) {
+ if (data BTRFS_BLOCK_GROUP_METADATA use_cluster) {
last_ptr = root-fs_info-meta_alloc_cluster;
if (!btrfs_test_opt(root, SSD))
empty_cluster = 64 * 1024;
}
- if ((data BTRFS_BLOCK_GROUP_DATA) btrfs_test_opt(root, SSD)) {
+ if ((data BTRFS_BLOCK_GROUP_DATA) use_cluster
+ btrfs_test_opt(root, SSD)) {
last_ptr = root-fs_info-data_alloc_cluster;
}
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs: fix memory leak in free_log_tree
To avoid memory leak, log-commit_root should be free, too. Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com --- fs/btrfs/tree-log.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index 2c3ed40..f2465f1 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -2124,6 +2124,7 @@ static void free_log_tree(struct btrfs_trans_handle *trans, } free_extent_buffer(log-node); + free_extent_buffer(log-commit_root); kfree(log); } -- 1.6.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix (latent?) memory corruption in btrfs_encode_fh()
The earlier checks only cover the two smaller cases, and hence if the
caller specified size is less than what's needed to fit
parent_root_objectid unrelated memory may get overwritten.
Signed-off-by: Jan Beulich jbeul...@novell.com
---
fs/btrfs/export.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.36-rc7/fs/btrfs/export.c
+++ 2.6.36-rc7-btrfs-encode-fh/fs/btrfs/export.c
@@ -46,6 +46,8 @@ static int btrfs_encode_fh(struct dentry
spin_unlock(dentry-d_lock);
if (parent_root_id != fid-root_objectid) {
+ if (*max_len BTRFS_FID_SIZE_CONNECTABLE_ROOT)
+ return 255;
fid-parent_root_objectid = parent_root_id;
len = BTRFS_FID_SIZE_CONNECTABLE_ROOT;
type = FILEID_BTRFS_WITH_PARENT_ROOT;
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Btrfs: add support for mixed data+metadata block groups V2
On Thu, Oct 07, 2010 at 04:10:50PM +0800, Ian Kent wrote:
On Wed, 2010-10-06 at 16:21 -0400, Josef Bacik wrote:
There are just a few things that need to be fixed in the kernel to support
mixed
data+metadata block groups. Mostly we just need to make sure that if we are
using mixed block groups that we continue to allocate mixed block groups as
we
need them. Also we need to make sure __find_space_info will find our space
info
if we search for DATA or METADATA only. Tested this with xfstests and it
works
nicely. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
V1-V2: In do_chunk_alloc I was changing flags to == space_info-flags,
which
isn't right since space_info doesn't carry the RAID profiles anymore, so
instead
check to see if the space info has DATA and METADATA set and if so set that
in
the flags as well.
fs/btrfs/extent-tree.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 91a0a41..27eddb3 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -547,7 +547,7 @@ static struct btrfs_space_info
*__find_space_info(struct btrfs_fs_info *info,
rcu_read_lock();
list_for_each_entry_rcu(found, head, list) {
- if (found-flags == flags) {
+ if (found-flags flags) {
rcu_read_unlock();
return found;
}
@@ -3267,6 +3267,15 @@ static int do_chunk_alloc(struct btrfs_trans_handle
*trans,
spin_unlock(space_info-lock);
/*
+* If we have mixed data/metadata chunks we want to make sure we keep
+* allocating mixed chunks instead of individual chunks.
+*/
+ if ((space_info-flags (BTRFS_BLOCK_GROUP_DATA |
+ BTRFS_BLOCK_GROUP_METADATA)) ==
+ (BTRFS_BLOCK_GROUP_DATA | BTRFS_BLOCK_GROUP_METADATA))
+ flags |= (BTRFS_BLOCK_GROUP_DATA | BTRFS_BLOCK_GROUP_METADATA);
This sort of construct appears a few times.
Personally, I prefer a macroish (read 'inline function') construct,
perhaps with a longish name if needed, than multiple line breaks within
a logical expression. IMHO, having multiple line breaks makes the code
somewhat harder to read.
Agreed I thought of that after I hit send. I'll clean this up and resend,
thanks,
Josef
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Can you please define snapshot and subvolume?
I have difficulties grabbing these two concepts. As far as I can tell, a snapshot is an instant, synchronized, photography of the filesystem at a given point in time; a subvolume is a subroot to a btrfs filesystem. While I fully understand (and use) the purpose of snapshots, I don't quite fathom the use case for subvolumes, apart from btrfs-convert... Why has btrfs grown such a feature in the first place? Can someone give me a use case for them? -- Francis Galiegue, fgalie...@gmail.com It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries (Stéphane Faroult, in The Art of SQL, ISBN 0-596-00894-5) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs: add support for mixed data+metadata block groups V3
There are just a few things that need to be fixed in the kernel to support mixed
data+metadata block groups. Mostly we just need to make sure that if we are
using mixed block groups that we continue to allocate mixed block groups as we
need them. Also we need to make sure __find_space_info will find our space info
if we search for DATA or METADATA only. Tested this with xfstests and it works
nicely. Thanks,
Signed-off-by: Josef Bacik jo...@redhat.com
---
V2-V3: Add btrfs_mixed_space_info helper
V1-V2: In do_chunk_alloc I was changing flags to == space_info-flags, which
isn't right since space_info doesn't carry the RAID profiles anymore, so instead
check to see if the space info has DATA and METADATA set and if so set that in
the flags as well.
fs/btrfs/ctree.h |6 ++
fs/btrfs/extent-tree.c | 22 +++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 1ecd8f6..86a4f4b 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2043,6 +2043,12 @@ static inline struct dentry *fdentry(struct file *file)
return file-f_path.dentry;
}
+static inline bool btrfs_mixed_space_info(struct btrfs_space_info *space_info)
+{
+ return ((space_info-flags BTRFS_BLOCK_GROUP_METADATA)
+ (space_info-flags BTRFS_BLOCK_GROUP_DATA));
+}
+
/* extent-tree.c */
void btrfs_put_block_group(struct btrfs_block_group_cache *cache);
int btrfs_run_delayed_refs(struct btrfs_trans_handle *trans,
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 91a0a41..ed84271 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -547,7 +547,7 @@ static struct btrfs_space_info *__find_space_info(struct
btrfs_fs_info *info,
rcu_read_lock();
list_for_each_entry_rcu(found, head, list) {
- if (found-flags == flags) {
+ if (found-flags flags) {
rcu_read_unlock();
return found;
}
@@ -3267,6 +3267,13 @@ static int do_chunk_alloc(struct btrfs_trans_handle
*trans,
spin_unlock(space_info-lock);
/*
+* If we have mixed data/metadata chunks we want to make sure we keep
+* allocating mixed chunks instead of individual chunks.
+*/
+ if (btrfs_mixed_space_info(space_info))
+ flags |= (BTRFS_BLOCK_GROUP_DATA | BTRFS_BLOCK_GROUP_METADATA);
+
+ /*
* if we're doing a data chunk, go ahead and make sure that
* we keep a reasonable number of metadata chunks allocated in the
* FS as well.
@@ -4793,6 +4800,7 @@ static noinline int find_free_extent(struct
btrfs_trans_handle *trans,
bool found_uncached_bg = false;
bool failed_cluster_refill = false;
bool failed_alloc = false;
+ bool use_cluster = true;
u64 ideal_cache_percent = 0;
u64 ideal_cache_offset = 0;
@@ -4807,16 +4815,24 @@ static noinline int find_free_extent(struct
btrfs_trans_handle *trans,
return -ENOSPC;
}
+ /*
+* If the space info is for both data and metadata it means we have a
+* small filesystem and we can't use the clustering stuff.
+*/
+ if (btrfs_mixed_space_info(space_info))
+ use_cluster = false;
+
if (orig_root-ref_cows || empty_size)
allowed_chunk_alloc = 1;
- if (data BTRFS_BLOCK_GROUP_METADATA) {
+ if (data BTRFS_BLOCK_GROUP_METADATA use_cluster) {
last_ptr = root-fs_info-meta_alloc_cluster;
if (!btrfs_test_opt(root, SSD))
empty_cluster = 64 * 1024;
}
- if ((data BTRFS_BLOCK_GROUP_DATA) btrfs_test_opt(root, SSD)) {
+ if ((data BTRFS_BLOCK_GROUP_DATA) use_cluster
+ btrfs_test_opt(root, SSD)) {
last_ptr = root-fs_info-data_alloc_cluster;
}
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Can you please define snapshot and subvolume?
You may take a look at this article this isn't actually a explanation of why snapshots or subvolumes are used, but maybe you can read the importance of the difference from the context: http://www.h-online.com/open/features/Snapshots-and-subvolumes-747029.html On Thu, Oct 7, 2010 at 13:39, Francis Galiegue fgalie...@gmail.com wrote: I have difficulties grabbing these two concepts. As far as I can tell, a snapshot is an instant, synchronized, photography of the filesystem at a given point in time; a subvolume is a subroot to a btrfs filesystem. While I fully understand (and use) the purpose of snapshots, I don't quite fathom the use case for subvolumes, apart from btrfs-convert... Why has btrfs grown such a feature in the first place? Can someone give me a use case for them? -- Francis Galiegue, fgalie...@gmail.com It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries (Stéphane Faroult, in The Art of SQL, ISBN 0-596-00894-5) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can you please define snapshot and subvolume?
Just to tell you one of my use case, I do compilations of OpenWRT on a Btrfs filesystem, when I snapshot, I only snapshot the subvolume where all the sources are instead of the whole root filesystem, and when I need a snapshot of the root for backup purposes, only the root without all the snapshot (which are used to compile for different models of embedded devices) is snapshotted, which probably reduces the overhead (I can't tell for sure) and makes deletion instantaneous, the cleaner just wipes behind the subvolume remove command. On Thu, Oct 7, 2010 at 7:39 AM, Francis Galiegue fgalie...@gmail.com wrote: I have difficulties grabbing these two concepts. As far as I can tell, a snapshot is an instant, synchronized, photography of the filesystem at a given point in time; a subvolume is a subroot to a btrfs filesystem. While I fully understand (and use) the purpose of snapshots, I don't quite fathom the use case for subvolumes, apart from btrfs-convert... Why has btrfs grown such a feature in the first place? Can someone give me a use case for them? -- Francis Galiegue, fgalie...@gmail.com It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries (Stéphane Faroult, in The Art of SQL, ISBN 0-596-00894-5) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IOCTL #21 part two: btrfs progs patch, including iso 8601 timeout support
On Thu, Oct 7, 2010 at 1:10 AM, Goffredo Baroncelli kreij...@libero.it wrote:
On Wednesday, 06 October, 2010, David Nicol wrote:
the ISO 8601 duration support is very loose, but I believe it is
accurate for valid
In the man page and in the help the syntax is reported as:
btrfs filesystem reclaim path [timeout]
instead it should be
btrfs filesystem reclaim [path [timeout]]
and it has to be reported that path is optional and if it is omitted the
current CWD is taken.
D'oh! yes you are right.
2) I think that it is more reasonable avoid a strict iso 8601 syntax for the
time. I suggest to use a simple syntax like
0. - subsecond
s or nothing - seconds
m - minutes
h - hour
d - day
M - month (but make sense to wait up to a month ?)
[...]
That's what the function provides, aside from differentiating between
M and m instead of using the ISO8601 disambiguation rule (as explained
on wikipedia.) After sleeping on it I'm thinking that a better route
would be either
(1) having the timeout in seconds.subseconds and providing a separate
tool that will parse ISO8601 durations, which is suggested to invoke
in backticks. Greater reusability and fewer library functions linked
into the binaries for the win.
or
(2) only supporting the WDHMS designators, nothing larger, (not big-M
or Y), thus removing the ambiguity. Y or M before [TWDH] would be a
fatal error. No longer caring how many seconds in a year for the win.
3) As minor issue I have to point out that reclaim seems (to me) that the
user has to start this command in order to obtain more space, like if this
command starts a garbage collector. In any case the help/man page explain
clearly the behavior of the command.
My hope is that the current behavior is a temporary stand-in for
something to be developed later that will more aggressively collect
garbage.
+ switch (*endptr)
+ {
+ case 'P': /* anchor */ case 'p':
+ if (ptr P)
+ fprintf(stderr, ignoring non-initial P
+ in ISO8601 duration string %s\n, P);
+ break;
+ case 'Y': /* years */ case 'y':
+ component *= 12;
+ BIGM:
+ /* average days in a gregorian month */
+ component *= (365.2425 / 12.0);
+ /* ms in a day */
+ component *= ( 24 * 3600 * 1000 );
+ ms += component;
+ break;
+ case 'T': /* Time (not date) anchor */ case 't':
+ M_min = 1;
+ break;
+ case 'W': /* week */ case 'w':
+ component *= 7;
+ case 'D': /* day */ case 'd':
+ component *= 24 ;
+ case 'H': /* hour */ case 'h':
+ component *= 60;
+ M_min = 1;
+ case 'M': /* month, or minute */ case 'm':
+ if (!M_min++)
+ goto BIGM;
+ component *= 60;
[...]
In the function I suggest to avoid if possible a goto in a switch case. I
think that it is more clear to repeat few lines instead of doing a goto.
Well it isn't a whole Duff's device, but by choosing to use the goto
here the constant of year length in seconds only has to appear once. I
guess I could define a symbol. Stacking the cases like this should cut
down on the number of jumps in the compiled machine code, as each
break in a switch is short for a jump to the end. I'd be okay with
testing nearer the top so the jump is forward instead of backwards.
I believe that having a goto in a switch statement with a lot of
fallthroughs in its logic (such as this one) highlights that a C
switch statement makes a jump table rather than being a macro for an
oddly crippled series of else-if statements referring to the same
topic, which is what some providers of switch syntax in certain other
languages like to do with the construct.
review: http://en.wikipedia.org/wiki/Duff's_device
and I'm trying to optimize for size, not speed.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can you please define snapshot and subvolume?
On Thu, Oct 07, 2010 at 08:30:31AM -0400, Jérôme Poulin wrote: Just to tell you one of my use case, I do compilations of OpenWRT on a Btrfs filesystem, when I snapshot, I only snapshot the subvolume where all the sources are instead of the whole root filesystem, and when I need a snapshot of the root for backup purposes, only the root without all the snapshot (which are used to compile for different models of embedded devices) is snapshotted, which probably reduces the overhead (I can't tell for sure) and makes deletion instantaneous, the cleaner just wipes behind the subvolume remove command. BTW, it would be very useful to be able to turn existing directories into subvolumes. Mike -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can you please define snapshot and subvolume?
+1 from me On Thu, Oct 7, 2010 at 15:18, Mike Hommey m...@glandium.org wrote: On Thu, Oct 07, 2010 at 08:30:31AM -0400, Jérôme Poulin wrote: Just to tell you one of my use case, I do compilations of OpenWRT on a Btrfs filesystem, when I snapshot, I only snapshot the subvolume where all the sources are instead of the whole root filesystem, and when I need a snapshot of the root for backup purposes, only the root without all the snapshot (which are used to compile for different models of embedded devices) is snapshotted, which probably reduces the overhead (I can't tell for sure) and makes deletion instantaneous, the cleaner just wipes behind the subvolume remove command. BTW, it would be very useful to be able to turn existing directories into subvolumes. Mike -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IOCTL #21 part two: btrfs progs patch, including iso 8601 timeout support
anyway I think I got the logic wrong: the function as given yesterday would misparse PT1M1M -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
snapshot consumed space
Is there any way (or future planned functionality) to obtain information how much space can I gain with removing given snapshot from btrfs filesystem? In case I am using snapshots as backup I would like to know in advance if removing some snapshots can give me reasonable amount of free space or I should look somewhere else to find what is consuming my disk space. Roman Kapusta -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IOCTL #21 part two: btrfs progs patch, including iso 8601 timeout support
On Thu, Oct 7, 2010 at 9:25 AM, David Nicol davidni...@gmail.com wrote: anyway I think I got the logic wrong: the function as given yesterday would misparse PT1M1M no it wouldn't! because of the post-increment on the how-to-parse 'M' state variable, the BIGM label can only get jumped to the first time, and not following T, W, D or H. Rearranging it to have a forward jump would lose this. Better to have an initial sanity-check pass to verify that all non-numerics are expected and in an acceptable order, and switch one of the kinds of Ms to some other letter at that time, then zip through the pieces with a case statement with no logic in it at all, just stacked multiplications. Goffredo -- this thinking-out-loud is not noise? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IOCTL #21 part two: btrfs progs patch, including iso 8601 timeout support
On Thu, Oct 7, 2010 at 1:10 AM, Goffredo Baroncelli kreij...@libero.it wrote:
Please the next time put your patch inline or it is more difficult to
highlight a suggestion.
* drop support for years and months, except as identified usage errors
* lower-case 'm' now minutes
* escalate syntax warnings to fatal exits
diff --git a/iso8601toms.c b/iso8601toms.c
index a1ee9bd..f982d34 100644
--- a/iso8601toms.c
+++ b/iso8601toms.c
@@ -25,6 +25,8 @@
accept a non-integer as the last numeric component
+always treats m as minutes
+
it silently accepts:
out of order duration type letters
@@ -35,10 +37,12 @@
non-integers in any position
- it warns on:
+ it halts and catches fire on:
P or p appearing somewhere besides the beginning of the string
+Attempts to use Years or Months
+
unrecognized characters
@@ -53,7 +57,6 @@ unsigned long iso8601toms(char *P){
char *ptr;
char *endptr;
short M_min = 0;
-
ms = 0UL;
ptr = P;
for(;;){
@@ -62,18 +65,13 @@ unsigned long iso8601toms(char *P){
{
case 'P': /* anchor */ case 'p':
if (ptr P)
-fprintf(stderr, ignoring non-initial P
- in ISO8601 duration string %s\n, P);
- break;
- case 'Y': /* years */ case 'y':
- component *= 12;
- BIGM:
- /* average days in a gregorian month */
- component *= (365.2425 / 12.0);
- /* ms in a day */
- component *= ( 24 * 3600 * 1000 );
- ms += component;
- break;
+fprintf(stderr, non-initial P
+ in duration string %s\n, P);
+ exit (-1);
+ case 'Y': /* year */ case 'y':
+fprintf(stderr, Years are not supported
+ in duration string %s\n, P);
+ exit (-1);
case 'T': /* Time (not date) anchor */ case 't':
M_min = 1;
break;
@@ -84,9 +82,15 @@ unsigned long iso8601toms(char *P){
case 'H': /* hour */ case 'h':
component *= 60;
M_min = 1;
- case 'M': /* month, or minute */ case 'm':
- if (!M_min++)
- goto BIGM;
+ case 'M': /* month, or minute */
+ if (M_min == 0 ){
+fprintf(stderr, Months are not supported
+ in duration string %s\n
+ use 'm' instead or prefix a 'T'\n
+ , P);
+ exit (-1);
+ };
+ case 'm': /* minute */
component *= 60;
case 'S': /* second */ case 's':
case '\0': /* default to second */
@@ -96,10 +100,11 @@ unsigned long iso8601toms(char *P){
default:
fprintf(stderr,
-ignoring unexpected char [%c]
-in iso8601 duration string %s\n,
+unexpected char [%c] in duration string %s\n
+valid designators are [WwDdHhMmSs] with implied
trailing S.\n,
*endptr, P
);
+ exit (-1);
};
if (!*endptr)
return (ms);
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
system crash at mounting of btrfs
I have a weird problem concerning 5 btrfs partitions on 3 different disks: My system became slow and started to hang and go, so I shut it down and it hang totally whilst shutting down. With the sysrq shortcut I could kill it and restart. Booting didn't work any more throwing me into a shell at initramfs. I booted from a CD and tried to mount the first btrfs partition, the system hung up after about 1 sec, just throwing killed to the shell. I tried (after reboot) to mount the 4 other partitions which are on different disks: the failure is always the same. I also tried mount options as degraded, read-only w/o success. But btrfsck works flawless, also btrfsctl -A, no crashes. Any other partition on the same disk like ext4 mount perfectly. I tried it with 3 kernels from the 2.5.35 series. My system is a AMD64, so I put one SSD disk as an external drive (USB) to a laptop running a 32bit system, it crashed the same at my wanting to mount the partition. This is my config: $uname -a Linux ubuntu 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686 GNU/Linux Here is a dmesg trace during booting from the CD, it not the crash yet. [7.782823] Btrfs loaded [7.786081] xor: automatically using best checksumming function: pIII_sse [7.804000]pIII_sse : 11626.000 MB/sec [7.804001] xor: using function: pIII_sse (11626.000 MB/sec) [7.805746] device-mapper: dm-raid45: initialized v0.2594b [7.851186] device fsid 3a4b4bc6c07de70b-2b32b3df70d2459f devid 1 transid 407064 /dev/sda2 [7.881078] Btrfs detected SSD devices, enabling SSD mode [7.923553] [ cut here ] [7.923556] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs/tree-log.c:813! [7.923558] invalid opcode: [#1] SMP [7.923561] last sysfs file: /sys/devices/virtual/bdi/btrfs-1/uevent [7.923562] Modules linked in: dm_raid45 xor btrfs zlib_deflate crc32c libcrc32c nouveau ttm drm_kms_helper usbhid hid usb_storage drm sky2 firewire_ohci firewire_core intel_agp crc_itu_t ahci pata_jmicron libahci agpgart i2c_algo_bit [7.923577] [7.923579] Pid: 453, comm: exe Not tainted 2.6.35-22-generic #33-Ubuntu P5K-E/P5K-E [7.923582] EIP: 0060:[f9c44024] EFLAGS: 00010246 CPU: 0 [7.923590] EIP is at add_inode_ref+0x3f4/0x410 [btrfs] [7.923592] EAX: EBX: 0097 ECX: EDX: 0274 [7.923594] ESI: 0002 EDI: f6fe8af0 EBP: c1257c30 ESP: c1257bd4 [7.923596] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [7.923598] Process exe (pid: 453, ti=c1256000 task=f6a3 task.ti=c1256000) [7.923599] Stack: [7.923600] c1257be8 c1257be8 c0132ba6 f6fe8af0 0011 c1257bf0 f9c2d2c1 c1257c30 [7.923605] 0 f9c21d37 c1257c20 f6f9b000 f643887c 0004 f6fe8af0 [7.923610] 0 f68e6000 f7156000 fffb6000 fffb6000 0097 0002 f6fe8af0 c1257c94 [7.923615] Call Trace: [7.923620] [c0132ba6] ? kunmap_atomic+0x66/0x80 [7.923628] [f9c2d2c1] ? unmap_extent_buffer+0x11/0x20 [btrfs] [7.923637] [f9c21d37] ? btrfs_item_size+0xc7/0xd0 [btrfs] [7.923644] [f9c45a46] ? replay_one_buffer+0x246/0x320 [btrfs] [7.923651] [f9c423a9] ? walk_down_log_tree+0x219/0x3b0 [btrfs] [7.923658] [f9c425e9] ? walk_log_tree+0xa9/0x1d0 [btrfs] [7.923665] [f9c44d94] ? btrfs_recover_log_trees+0x1d4/0x2b0 [btrfs] [7.923672] [f9c45800] ? replay_one_buffer+0x0/0x320 [btrfs] [7.923680] [f9c0d07c] ? open_ctree+0x101c/0x14c0 [btrfs] [7.923686] [f9bee672] ? btrfs_fill_super+0x52/0x110 [btrfs] [7.923690] [c0356069] ? strlcpy+0x39/0x50 [7.923695] [f9beebbd] ? btrfs_get_sb+0x24d/0x2d0 [btrfs] [7.923699] [c020f66f] ? __alloc_percpu+0xf/0x20 [7.923701] [c0231109] ? alloc_vfsmnt+0xf9/0x130 [7.923704] [c021aee4] ? vfs_kern_mount+0x74/0x1c0 [7.923707] [c022f493] ? get_fs_type+0x33/0xb0 [7.923709] [c021b08e] ? do_kern_mount+0x3e/0xe0 [7.923711] [c023260c] ? do_mount+0x1dc/0x220 [7.923714] [c02326bb] ? sys_mount+0x6b/0xa0 [7.923717] [c05c90a4] ? syscall_call+0x7/0xb [7.923718] Code: e8 42 b3 fa ff 8b 45 d4 e8 5a 87 5e c6 8b 45 cc e8 52 87 5e c6 31 c0 83 c4 50 5b 5e 5f 5d c3 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 0f 0b eb fe 8d b6 00 00 00 [7.923746] EIP: [f9c44024] add_inode_ref+0x3f4/0x410 [btrfs] SS:ESP 0068:c1257bd4 [7.923755] ---[ end trace 2b634c981d89a441 ]--- Any help how to get my data off those disk is seriously appreciated. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can you please define snapshot and subvolume?
On Thu, Oct 7, 2010 at 6:39 AM, Francis Galiegue fgalie...@gmail.com wrote: While I fully understand (and use) the purpose of snapshots, I don't quite fathom the use case for subvolumes, apart from btrfs-convert... Why has btrfs grown such a feature in the first place? Can someone give me a use case for them? I'm new here; I trust that someone will correct me if wrong: As I understand it, since snapshotting works on volumes, having subvolumes allows a smaller thing that you can take a snapshot of. A use case? One could give each user on a multi-user system their own subvolume rather than their own directory, under /home/... and then take snapshots of these home directories to implement regular backups (1)without duplicating unchanged files and (2) with independence between the users. As to why they exist, I understand that they began as an implementation detail of snapshots, rather than their creation having been driven by the needs of a particular use case, and one could legitimately criticize currently offered use cases (such as the one above) as contrived. I believe it is fair to consider a new subvolume as equivalent of a snapshot of an empty file system. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can you please define snapshot and subvolume?
On Thu, Oct 7, 2010 at 8:18 AM, Mike Hommey m...@glandium.org wrote: BTW, it would be very useful to be able to turn existing directories into subvolumes. does a (link,unlink) move work across subvolumes? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can you please define snapshot and subvolume?
On Thursday, 07 October, 2010, David Nicol wrote: On Thu, Oct 7, 2010 at 8:18 AM, Mike Hommey m...@glandium.org wrote: BTW, it would be very useful to be able to turn existing directories into subvolumes. does a (link,unlink) move work across subvolumes? The link across subvolumes is not allowable. In the beginning it was possible, but that was source of bugs. See the thread Hard link across subvolumes http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03286.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) kreij...@inwind.it Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can you please define snapshot and subvolume?
If I were to use the defrag option in btrfsctl, $ btrfsctl -d / would it also defragment the subvolumes under the root? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow link/Capacity changed + Kernel OOPS... possible hardware issues, ideas?
Hi, can anyone point me in the right direction? it looks like maybe the SSD is failing to me (all the slow link and capacity changed to 0 stuff), but i really don't know. i knew there was a reason they were selling these things cheap on Newegg!!! Yes, the read errors are coming all the way up from the hardware; I don't think this is a btrfs problem. There's not much btrfs could do to help, except (over time) grow to handle I/O errors without BUG()ing out. -- Chris Ball c...@laptop.org One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow link/Capacity changed + Kernel OOPS... possible hardware issues, ideas?
On Thu, Oct 7, 2010 at 10:20 PM, Chris Ball c...@laptop.org wrote: Hi, can anyone point me in the right direction? it looks like maybe the SSD is failing to me (all the slow link and capacity changed to 0 stuff), but i really don't know. i knew there was a reason they were selling these things cheap on Newegg!!! Yes, the read errors are coming all the way up from the hardware; I don't think this is a btrfs problem. There's not much btrfs could do to help, except (over time) grow to handle I/O errors without BUG()ing out. hmm, i'll have to keep playing with it i guess. /dev/sda1 is a ext2 boot partition; i tar + ssh'ed that several times to my other machine without problems... i thought it would trip an issue if it really was hardware, but it didn't, even after 30+ times. i'll try to reinstall i guess, unless anyone has other input. i'll probably just have to ask ASUS to replace it, because i don't think i've even had it 6mo yet... :-O thanks, C Anthony -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
