Re: Patches for BTRFS (mail-server slow down in 3.0 and more)

2011-10-28 Thread Chris Mason
On Sat, Oct 29, 2011 at 02:35:16AM -0200, Alexandre Oliva wrote:
> On Oct 28, 2011, Marcel Lohmann  wrote:
> 
> > I would really appreciate if you could send me the patches.
> 
> Here are the patches I mentioned on IRC.  I've sent two of them to Josef
> for him to push upstream, but I'm not sure he posted them here for I'm
> not on the list (yet?).  The other two are newer, and the last one is
> definitely not for inclusion (just for testing or as a temporary
> work-around).

The last one isn't a bad idea, but please do make a real mount option
for it ;)

-chris
--
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: Btrfs progs git repo on kernel.org

2011-10-28 Thread Chris Mason
On Fri, Oct 28, 2011 at 07:27:56PM +0300, Sergei Trofimovich wrote:
> > Hi everyone,
> > 
> > I've pulled in Hugo's integration tree, minus the features that were not
> > yet in the kernel.  This also has a few small commits that I had queued
> > up outside of the fsck work.
> > 
> > Hugo, many thanks for keeping up the integration tree!  Taking out the
> > features not in the kernel meant I had to rebase it the commits, I'm
> > sorry about that.
> > 
> > The code from the integration tree is here:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
> 
> Sounds great! Should we treat is as new home of a thing called "-unstable" 
> before?
> 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
> 
> Or you are planning to restore that repo as well?

That's a good point, I'll see if I can make the -unstable a link.  Still
figuring out the new git interface.

But yes, this is the new home of the progs.

-chris

--
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: Patches for BTRFS (mail-server slow down in 3.0 and more)

2011-10-28 Thread Alexandre Oliva
On Oct 28, 2011, Marcel Lohmann  wrote:

> I would really appreciate if you could send me the patches.

Here are the patches I mentioned on IRC.  I've sent two of them to Josef
for him to push upstream, but I'm not sure he posted them here for I'm
not on the list (yet?).  The other two are newer, and the last one is
definitely not for inclusion (just for testing or as a temporary
work-around).

I've been using the first 3 with some success on a couple of mail
servers: I haven't hit the ridiculous slow downs from frequent
unsuccessful calls of setup_cluster_no_bitmap after a while, like I did
with 3.0 (and 3.1) any more.

However, the excess use of metadata that I've experienced on ceph OSDs
isn't fixed by them.  A btrfs balance with the first 3 still has 22GB of
metadata block groups even though only 4.1GB of metadata are in use, or
19GB of metadata with only 2GB of metadata in use.  With the 4th patch
and -o clear_cache, the first rebalancing of the 22GB-metadata
filesystem got it down to 8GB; the second fs is still on rebalancing
~800GB (wishlist mental note: introduce some means to rebalance only the
metadata)

Here are the patches, against 3.1-libre (should apply cleanly on 3.1).


--- Begin Message ---
Parameterized clusters on minimum total size and minimum chunk size,
without an upper bound.  Don't tolerate fragmentation for SSD_SPREAD;
accept some fragmentation for metadata but try to keep data dense.

Signed-off-by: Alexandre Oliva 
---
 fs/btrfs/free-space-cache.c |   64 +++---
 1 files changed, 35 insertions(+), 29 deletions(-)

diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 41ac927..4973816 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2092,8 +2092,8 @@ static int btrfs_bitmap_cluster(struct 
btrfs_block_group_cache *block_group,
struct btrfs_free_space_ctl *ctl = block_group->free_space_ctl;
unsigned long next_zero;
unsigned long i;
-   unsigned long search_bits;
-   unsigned long total_bits;
+   unsigned long want_bits;
+   unsigned long min_bits;
unsigned long found_bits;
unsigned long start = 0;
unsigned long total_found = 0;
@@ -2102,8 +2102,8 @@ static int btrfs_bitmap_cluster(struct 
btrfs_block_group_cache *block_group,
 
i = offset_to_bit(entry->offset, block_group->sectorsize,
  max_t(u64, offset, entry->offset));
-   search_bits = bytes_to_bits(bytes, block_group->sectorsize);
-   total_bits = bytes_to_bits(min_bytes, block_group->sectorsize);
+   want_bits = bytes_to_bits(bytes, block_group->sectorsize);
+   min_bits = bytes_to_bits(min_bytes, block_group->sectorsize);
 
 again:
found_bits = 0;
@@ -2112,7 +2112,7 @@ again:
 i = find_next_bit(entry->bitmap, BITS_PER_BITMAP, i + 1)) {
next_zero = find_next_zero_bit(entry->bitmap,
   BITS_PER_BITMAP, i);
-   if (next_zero - i >= search_bits) {
+   if (next_zero - i >= min_bits) {
found_bits = next_zero - i;
break;
}
@@ -2132,9 +2132,9 @@ again:
if (cluster->max_size < found_bits * block_group->sectorsize)
cluster->max_size = found_bits * block_group->sectorsize;
 
-   if (total_found < total_bits) {
+   if (total_found < want_bits) {
i = find_next_bit(entry->bitmap, BITS_PER_BITMAP, next_zero);
-   if (i - start > total_bits * 2) {
+   if (i - start > want_bits * 2) {
total_found = 0;
cluster->max_size = 0;
found = false;
@@ -2180,8 +2180,8 @@ setup_cluster_no_bitmap(struct btrfs_block_group_cache 
*block_group,
 * We don't want bitmaps, so just move along until we find a normal
 * extent entry.
 */
-   while (entry->bitmap) {
-   if (list_empty(&entry->list))
+   while (entry->bitmap || entry->bytes < min_bytes) {
+   if (entry->bitmap && list_empty(&entry->list))
list_add_tail(&entry->list, bitmaps);
node = rb_next(&entry->offset_index);
if (!node)
@@ -2196,10 +2196,8 @@ setup_cluster_no_bitmap(struct btrfs_block_group_cache 
*block_group,
last = entry;
prev = entry;
 
-   while (window_free <= min_bytes) {
-   node = rb_next(&entry->offset_index);
-   if (!node)
-   return -ENOSPC;
+   for (node = rb_next(&entry->offset_index); node;
+node = rb_next(&entry->offset_index)) {
entry = rb_entry(node, struct btrfs_free_space, offset_index);
 
if (entry->bitmap) {
@@ -2208,12 +2206,19 @@ setup_cluster_no_bitmap(struct btrfs_block_group_cache 
*block_group,
continue;

Re: Unable to mount btrfs partition

2011-10-28 Thread email


On Fri, 28 Oct 2011 22:09:47 +0100, Hugo Mills  
wrote:

On Fri, Oct 28, 2011 at 08:36:28PM +, em...@joachim-neu.de wrote:

Today I downgraded from Ubuntu's APT repo "oneiric-proposed" (which
brings some kernel 3.0.0-13) back to the standard repo "oneiric".


   It's odd that switching from one 3.0.0 to another would cause
something bad to happen. Did something else happen in the process,
like a reboot without a clean shutdown? (This includes power loss,
suspend and failure to resume, and Alt-SysRq-b).


I agree, but there was no power loss or anything. Maybe the fs didn't 
unmount correctly or fast enough when rebooting?



Now I'm not able to mount my btrfs / and /home (both on the same
partition) anymore:

device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0
parent transid verify failed on 77078528 wanted 83774 found 84226
parent transid verify failed on 77078528 wanted 83774 found 84226
parent transid verify failed on 77078528 wanted 83774 found 84226
parent transid verify failed on 77078528 wanted 83774 found 84226
btrfs: open_ctree failed

The boot process drops to the initramfs shell with no btrfsck
available.


   It wouldn't make any difference if it were -- btrfsck doesn't
actually fix anything, I'm afraid. This error message is regrettably
generic, and covers a whole range of evils. It's possible that 3.1 
may

be able to deal swith the breakage ufficiently well to allow you to
boot and copy your files.


I'll give the 3.1 kernel a try right after "restore" finished which is 
running right now and doing quite a good job so far (as far as my / is 
concerned, lets wait for the /home).


What do the above error messages indicate? Is there an incrementing 
number for every transaction and the number of the most recent 
transaction is stored somewhere and those messages occur once those 
numbers are out of sync somehow? Is it possible to "just" discard the 
last transactions? I would not mind, better loose a day than a month... 
Why is the message there three times? Is this information stored in a 
couple of backups? If so: can't I use any of the other backups 
temporarily? "restore" opens the fs in a ro recovery mode somehow where 
it ignores those errors. Is it possible to "force" the btrfs driver to 
load the fs in this recovery mode as readonly, too?



I tried to boot with both the "new" 3.0.0-13 kernel and
the old 3.0.0-12 and 3.0.0-11 kernels -- no success. I'm running a
live cd right now with 3.0.0-12 and I get the above error no matter
what I do: no mount, no fsck, no nothing.

I really hope someone can help me get my data back...


   You could try using a 3.1 kernel, as I suggested above. Failing
that, in josef's git repository at [1], you will find a tool called
"restore". This should allow you to copy any files that had been
modified since your last backup. If you haven't got backups, you
*really* should look into getting some before continuing to use a
filesystem marked as EXPERIMENTAL...

   Hugo.


Thanks a lot for your help so far. I hope "restore" will do the trick, 
if not I'll give kernel 3.1 a try.


Joachim



[1] https://github.com/josefbacik/btrfs-progs


--
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: Unable to mount btrfs partition

2011-10-28 Thread Hugo Mills
On Fri, Oct 28, 2011 at 08:36:28PM +, em...@joachim-neu.de wrote:
> Today I downgraded from Ubuntu's APT repo "oneiric-proposed" (which
> brings some kernel 3.0.0-13) back to the standard repo "oneiric".

   It's odd that switching from one 3.0.0 to another would cause
something bad to happen. Did something else happen in the process,
like a reboot without a clean shutdown? (This includes power loss,
suspend and failure to resume, and Alt-SysRq-b).

> Now I'm not able to mount my btrfs / and /home (both on the same
> partition) anymore:
> 
> device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0
> parent transid verify failed on 77078528 wanted 83774 found 84226
> parent transid verify failed on 77078528 wanted 83774 found 84226
> parent transid verify failed on 77078528 wanted 83774 found 84226
> parent transid verify failed on 77078528 wanted 83774 found 84226
> btrfs: open_ctree failed
> 
> The boot process drops to the initramfs shell with no btrfsck
> available.

   It wouldn't make any difference if it were -- btrfsck doesn't
actually fix anything, I'm afraid. This error message is regrettably
generic, and covers a whole range of evils. It's possible that 3.1 may
be able to deal swith the breakage ufficiently well to allow you to
boot and copy your files.

> I tried to boot with both the "new" 3.0.0-13 kernel and
> the old 3.0.0-12 and 3.0.0-11 kernels -- no success. I'm running a
> live cd right now with 3.0.0-12 and I get the above error no matter
> what I do: no mount, no fsck, no nothing.
> 
> I really hope someone can help me get my data back...

   You could try using a 3.1 kernel, as I suggested above. Failing
that, in josef's git repository at [1], you will find a tool called
"restore". This should allow you to copy any files that had been
modified since your last backup. If you haven't got backups, you
*really* should look into getting some before continuing to use a
filesystem marked as EXPERIMENTAL...

   Hugo.

[1] https://github.com/josefbacik/btrfs-progs

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
 --- If you're not part of the solution, you're part --- 
   of the precipiate.


signature.asc
Description: Digital signature


Unable to mount btrfs partition

2011-10-28 Thread email


Hello!

Today I downgraded from Ubuntu's APT repo "oneiric-proposed" (which 
brings some kernel 3.0.0-13) back to the standard repo "oneiric".


Now I'm not able to mount my btrfs / and /home (both on the same 
partition) anymore:


device fsid SOME-UUID devid 1 transid 84229 /dev/dm-0
parent transid verify failed on 77078528 wanted 83774 found 84226
parent transid verify failed on 77078528 wanted 83774 found 84226
parent transid verify failed on 77078528 wanted 83774 found 84226
parent transid verify failed on 77078528 wanted 83774 found 84226
btrfs: open_ctree failed

The boot process drops to the initramfs shell with no btrfsck 
available. I tried to boot with both the "new" 3.0.0-13 kernel and the 
old 3.0.0-12 and 3.0.0-11 kernels -- no success. I'm running a live cd 
right now with 3.0.0-12 and I get the above error no matter what I do: 
no mount, no fsck, no nothing.


I really hope someone can help me get my data back...

Joachim
--
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 3/5] mm: try to distribute dirty pages fairly across zones

2011-10-28 Thread Wu Fengguang
[restore CC list]

> > I'm trying to understand where the performance gain comes from.
> > 
> > I noticed that in all cases, before/after patchset, nr_vmscan_write are all 
> > zero.
> > 
> > nr_vmscan_immediate_reclaim is significantly reduced though:
> 
> That's a good thing, it means we burn less CPU time on skipping
> through dirty pages on the LRU.
> 
> Until a certain priority level, the dirty pages encountered on the LRU
> list are marked PageReclaim and put back on the list, this is the
> nr_vmscan_immediate_reclaim number.  And only below that priority, we
> actually ask the FS to write them, which is nr_vmscan_write.

Yes, it is.

> I suspect this is where the performance improvement comes from: we
> find clean pages for reclaim much faster.

That explains how it could reduce CPU overheads. However the dd's are
throttled anyway, so I still don't understand how the speedup of dd page
allocations improve the _IO_ performance.

> > $ ./compare.rb -g 1000M -e nr_vmscan_immediate_reclaim 
> > thresh*/*-ioless-full-nfs-wq5-next-20111014+ 
> > thresh*/*-ioless-full-per-zone-dirty-next-20111014+
> > 3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+  
> > 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+  
> >     
> >560289.00   -98.5%  8145.00  
> > thresh=1000M/btrfs-100dd-4k-8p-4096M-1000M:10-X
> >576882.00   -98.4%  9511.00  
> > thresh=1000M/btrfs-10dd-4k-8p-4096M-1000M:10-X
> >651258.00   -98.8%  7963.00  
> > thresh=1000M/btrfs-1dd-4k-8p-4096M-1000M:10-X
> >   1963294.00   -85.4%286815.00  
> > thresh=1000M/ext3-100dd-4k-8p-4096M-1000M:10-X
> >   2108028.00   -10.6%   1885114.00  
> > thresh=1000M/ext3-10dd-4k-8p-4096M-1000M:10-X
> >   2499456.00   -99.9%  2061.00  
> > thresh=1000M/ext3-1dd-4k-8p-4096M-1000M:10-X
> >   2534868.00   -78.5%545815.00  
> > thresh=1000M/ext4-100dd-4k-8p-4096M-1000M:10-X
> >   2921668.00   -76.8%677177.00  
> > thresh=1000M/ext4-10dd-4k-8p-4096M-1000M:10-X
> >   2841049.00  -100.0%   779.00  
> > thresh=1000M/ext4-1dd-4k-8p-4096M-1000M:10-X
> >   2481823.00   -86.3%339342.00  
> > thresh=1000M/xfs-100dd-4k-8p-4096M-1000M:10-X
> >   2508629.00   -87.4%316614.00  
> > thresh=1000M/xfs-10dd-4k-8p-4096M-1000M:10-X
> >   2656628.00  -100.0%   678.00  
> > thresh=1000M/xfs-1dd-4k-8p-4096M-1000M:10-X
> >  24303872.00   -83.2%   4080014.00  TOTAL 
> > nr_vmscan_immediate_reclaim
> > 
> > If you'd like to compare any other vmstat items before/after patch,
> > let me know and I'll run the compare script to find them out.
> 
> I will come back to you on this, so tired right now.  But I find your
> scripts interesting ;-) Are those released and available for download
> somewhere?  I suspect every kernel hacker has their own collection of
> scripts to process data like this, maybe we should pull them all
> together and put them into a git tree!

Thank you for the interest :-)

I used to upload my writeback test scripts to kernel.org. However its
file service is not restored yet. So I attach the compare script here.
It's a bit hacky for now, which I hope can be improved over time to be
useful to other projects as well.

Thanks,
Fengguang


compare.rb
Description: application/ruby


Re: [patch 3/5] mm: try to distribute dirty pages fairly across zones

2011-10-28 Thread Wu Fengguang
Hi Johannes,

I tested this patchset over the IO-less dirty throttling one.
The below numbers show that

//improvements
1) write bandwidth increased by 1% in general
2) greatly reduced nr_vmscan_immediate_reclaim

//regression
3) much increased cpu %user and %system for btrfs

Thanks,
Fengguang
---

kernel before this patchset: 3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+
kernel after this patchset:  3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+

3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+  
3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
  
 2056.51+1.0%  2076.29  TOTAL write_bw  

 32260625.00   -86.0%   4532517.00  TOTAL 
nr_vmscan_immediate_reclaim   
   90.44   +25.7%   113.67  TOTAL cpu_user  

  113.05+9.9%   124.25  TOTAL cpu_system


3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+  
3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
  
   52.43+1.3%53.12  
thresh=1000M/btrfs-100dd-4k-8p-4096M-1000M:10-X
   52.72+0.8%53.16  
thresh=1000M/btrfs-10dd-4k-8p-4096M-1000M:10-X
   52.24+2.7%53.67  
thresh=1000M/btrfs-1dd-4k-8p-4096M-1000M:10-X
   35.52+1.2%35.94  
thresh=1000M/ext3-100dd-4k-8p-4096M-1000M:10-X
   39.37+1.6%39.98  
thresh=1000M/ext3-10dd-4k-8p-4096M-1000M:10-X
   47.52+0.5%47.75  
thresh=1000M/ext3-1dd-4k-8p-4096M-1000M:10-X
   47.13+1.1%47.64  
thresh=1000M/ext4-100dd-4k-8p-4096M-1000M:10-X
   52.28+3.0%53.86  
thresh=1000M/ext4-10dd-4k-8p-4096M-1000M:10-X
   54.34+1.0%54.87  
thresh=1000M/ext4-1dd-4k-8p-4096M-1000M:10-X
   47.63+0.3%47.78  
thresh=1000M/xfs-100dd-4k-8p-4096M-1000M:10-X
   51.25+2.1%52.34  
thresh=1000M/xfs-10dd-4k-8p-4096M-1000M:10-X
   52.66+2.5%54.00  
thresh=1000M/xfs-1dd-4k-8p-4096M-1000M:10-X
   54.63-0.0%54.63  
thresh=100M/btrfs-10dd-4k-8p-4096M-100M:10-X
   53.75+1.0%54.29  
thresh=100M/btrfs-1dd-4k-8p-4096M-100M:10-X
   54.14+0.4%54.35  
thresh=100M/btrfs-2dd-4k-8p-4096M-100M:10-X
   36.87-0.0%36.86  
thresh=100M/ext3-10dd-4k-8p-4096M-100M:10-X
   45.20-0.3%45.07  
thresh=100M/ext3-1dd-4k-8p-4096M-100M:10-X
   40.75-0.6%40.51  
thresh=100M/ext3-2dd-4k-8p-4096M-100M:10-X
   44.14+0.3%44.29  
thresh=100M/ext4-10dd-4k-8p-4096M-100M:10-X
   52.91+0.1%52.99  
thresh=100M/ext4-1dd-4k-8p-4096M-100M:10-X
   50.30+0.8%50.72  
thresh=100M/ext4-2dd-4k-8p-4096M-100M:10-X
   44.55+2.8%45.80  
thresh=100M/xfs-10dd-4k-8p-4096M-100M:10-X
   52.75+4.3%55.03  
thresh=100M/xfs-1dd-4k-8p-4096M-100M:10-X
   50.99+1.7%51.87  
thresh=100M/xfs-2dd-4k-8p-4096M-100M:10-X
   37.35+2.0%38.11  
thresh=10M/btrfs-10dd-4k-8p-4096M-10M:10-X
   53.32+2.3%54.55  
thresh=10M/btrfs-1dd-4k-8p-4096M-10M:10-X
   50.72+3.9%52.70  
thresh=10M/btrfs-2dd-4k-8p-4096M-10M:10-X
   32.05+0.7%32.27  
thresh=10M/ext3-10dd-4k-8p-4096M-10M:10-X
   43.91-1.2%43.39  
thresh=10M/ext3-1dd-4k-8p-4096M-10M:10-X
   42.37+0.3%42.50  
thresh=10M/ext3-2dd-4k-8p-4096M-10M:10-X
   35.04-1.9%34.36  
thresh=10M/ext4-10dd-4k-8p-4096M-10M:10-X
   52.93-0.4%52.73  
thresh=10M/ext4-1dd-4k-8p-4096M-10M:10-X
   49.24-0.0%49.22  
thresh=10M/ext4-2dd-4k-8p-4096M-10M:10-X
   30.96-0.8%30.73  
thresh=10M/xfs-10dd-4k-8p-4096M-10M:10-X
   54.30-0.8%53.89  
thresh=10M/xfs-1dd-4k-8p-4096M-10M:10-X
   45.63+1.2%46.17  
thresh=10M/xfs-2dd-4k-8p-4096M-10M:10-X
1.92-1.5% 1.89  
thresh=1M/btrfs-10dd-4k-8p-4096M-1M:10-X
2.28+5.9% 2.42  
thresh=1M/btrfs-1dd-4k-8p-4096M-1M:10-X
2.07-1.4% 2.04  
thresh=1M/btrfs-2dd-4

[PATCH] btrfs: Avoid creating new file in append-only dir when open(2) return error

2011-10-28 Thread Eryu Guan
Newly created file on btrfs inherits inode flags from parent directory,
so new inode created in append-only directory has S_APPEND flag set,
may_open() called by do_last() checks that flag then returns -EPERM,
but at that time the new inode is already created.

This can be reproduced by:
# mkdir -p /mnt/btrfs/append-only
# chattr +a /mnt/btrfs/append-only
# ./opentest /mnt/btrfs/append-only/newtestfile
# ls -l /mnt/btrfs/append-only/newtestfile

opentest will return 'Operation not permitted', but the ls shows that
newtestfile is already created.

# cat opentest.c
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
int fd;
fd = open(argv[1], O_RDWR|O_CREAT, 0666);
if (fd == -1)
perror("open failed");
return 0;
}

To avoid this, check BTRFS_INODE_APPEND flag first in btrfs_create before
really allocating new inode.

Cc: Chris Mason 
Signed-off-by: Eryu Guan 
---
 fs/btrfs/inode.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index b2d004a..18e9914 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "compat.h"
 #include "ctree.h"
 #include "disk-io.h"
@@ -4718,10 +4719,19 @@ static int btrfs_create(struct inode *dir, struct 
dentry *dentry,
struct inode *inode = NULL;
int drop_inode = 0;
int err;
+   int open_flag = nd->intent.open.file->f_flags;
unsigned long nr = 0;
u64 objectid;
u64 index = 0;
 
+   if (BTRFS_I(dir)->flags & BTRFS_INODE_APPEND) {
+   if ((open_flag & O_ACCMODE) != O_RDONLY &&
+   !(open_flag & O_APPEND))
+   return -EPERM;
+   if (open_flag & O_TRUNC)
+   return -EPERM;
+   }
+
/*
 * 2 for inode item and ref
 * 2 for dir items
-- 
1.7.7.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


[PATCH] Btrfs: don't try to touch sb->s_bdev

2011-10-28 Thread Ilya Dryomov
Btrfs uses anon bdevs, this is not needed.

Signed-off-by: Ilya Dryomov 
---
 fs/btrfs/volumes.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index f2a4cc7..afd6a1e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1376,8 +1376,6 @@ int btrfs_rm_device(struct btrfs_root *root, char 
*device_path)
 
next_device = list_entry(root->fs_info->fs_devices->devices.next,
 struct btrfs_device, dev_list);
-   if (device->bdev == root->fs_info->sb->s_bdev)
-   root->fs_info->sb->s_bdev = next_device->bdev;
if (device->bdev == root->fs_info->fs_devices->latest_bdev)
root->fs_info->fs_devices->latest_bdev = next_device->bdev;
 
-- 
1.7.6.3

--
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: Btrfs progs git repo on kernel.org

2011-10-28 Thread Sergei Trofimovich
> Hi everyone,
> 
> I've pulled in Hugo's integration tree, minus the features that were not
> yet in the kernel.  This also has a few small commits that I had queued
> up outside of the fsck work.
> 
> Hugo, many thanks for keeping up the integration tree!  Taking out the
> features not in the kernel meant I had to rebase it the commits, I'm
> sorry about that.
> 
> The code from the integration tree is here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git

Sounds great! Should we treat is as new home of a thing called "-unstable" 
before?

git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git

Or you are planning to restore that repo as well?

Thanks!

-- 

  Sergei


signature.asc
Description: PGP signature


Re: Unable to mount (or, why not to work late at night).

2011-10-28 Thread Stephane CHAZELAS
2011-10-28, 07:57(+07), Fajar A. Nugraha:
[...]
>> Already got 'em.  Everything that tries to even think about modifying stuff
>> (btrfs-zero-log, btrfsck, and btrfs-debug-tree) all dump core:
>
> Your last resort (for now, anyway) might be using "restore" from
> Josef's btrfs-progs: https://github.com/josefbacik/btrfs-progs
>
> It might be able to copy some data.

I also have got one FS in that same situation. I tried
everything on it including that "restore" (which bailed out with
those same error messages IIRC).

The only thing that got me a bit further was to use an alternate
superblock, though that screwed the FS even further as I need to
reboot the machine after trying to mount it (mount hangs and
there are some btrfs tasks using all the CPU time).

Fortunately, for that one, I had a not too old backup at the
block device level.

-- 
Stephane

--
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: btrfs fi defrag -c

2011-10-28 Thread Stephane CHAZELAS
2011-10-28, 10:25(+08), Li Zefan:
[...]
> # df . -h
> FilesystemSize  Used Avail Use% Mounted on
> /home/lizf/tmp/a  2.0G  409M  1.4G  23% /mnt

OK, why are we not gaining space after compression though?


> And I was not suprised, as there's a regression.
>
> With this fix:
>
> http://marc.info/?l=linux-btrfs&m=131495014823121&w=2
[...]

Thanks. That's the one that's scheduled for 3.2 and maybe 3.1.x,
right?

-- 
Stephane

--
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