Re: NFS support
On Wed, Nov 10, 2010 at 12:53:59PM +0800, Wenyi Liu wrote: Hi All: I found the project ideas about NFS support in btrfs wiki. But, I have long time to disconnect to the btrfs mail list. Can you give me the process of the support? Thanks!! NFS support already is there. 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
Re: labelling
On Wed, Nov 10, 2010 at 08:40:00AM +0100, Helmut Hullen wrote: Hallo, linux-btrfs, I have problems with btrfs labels. My way: 2-TByte-disk: mkfs.btrs LABEL=MM2 /dev/sdd2 worked. Mounting mount LABEL=MM2 /srv/MM worked. Additional 1.5-TByte-Disk: btrfs add device /dev/sdc3 /srv/MM ... balance ... worked. findfs LABEL=MM2 shows /dev/sdd2 (the first partition) file -s /dev/sdd2 file -s /dev/sdc3 shows LABEL=MM2 for both partitions (that's not good). No, this is both good and correct. You've got a single filesystem spanning multiple block devices. The *filesystem* possesses the label, and with btrfs you can mount the filesystem using *any* of the block devices that compose it, so both block devices should indeed show the FS label, which is what's happening here. Unmounting /srv/MM and mount LABEL=MM2 /srv/MM doesn't work now, it tries to mount /dev/sdd2 and mourns. mount /dev/sdd2 /srv/MM shows the same error message, What's the error message? What do you get in your kernel logs when you do this? This should work, so there's something wrong, but it's (probably) not to do with disk labels. mount /dev/sdc3 /srv/MM (mounting the added partition) works fine, the whole space is available. But what can I do with the 2 identical labels? How can I delete (or change) the label of the first btrfs partition? You can't, as I explained above. By the way: df shows about 3.4 TByte usable space (2 TByte and 1.5 TByte), but btrfs filesystem df /srv/MM tells Data: total=2.70TB, used=1.64TB I'm missing about 0.7 TByte! In btrfs filesystem df, the total field is the space that has been allocated to block groups. As more space is needed on the filesystem, the total field will increase to use up the additional raw storage (if you're using RAID1 or RAID10, this will be at a ratio of 2:1; with RAID0 or simple allocation, the ratio is 1:1). Hugo. -- === Hugo Mills: h...@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- In event of Last Trump, please form an orderly queue --- and await judgement. signature.asc Description: Digital signature
migrating drives (device delete)
Hi, running on Ubuntu server 10.10 (2.6.35-22-server) I've got a 160GB disk for / (/boot is on another partition with ext2). I added another 750GB drive with the following command: # btrfs device add /dev/sdb2 / # btrfs device balance / As far as I can see it is a RAID 0 and now full: # sudo btrfs filesystem show Label: none uuid: cd4fd4c1-0632-4cbe-bf3b-ba7a9acda1e0 Total devices 2 FS bytes used 291.62GB devid2 size 696.77GB used 146.63GB path /dev/sdb2 devid1 size 147.19GB used 146.64GB path /dev/sda2 Now I want to remove the smaller drive: # mount -t btrfs -o remount,degraded /dev/sda2 / # mount | grep /dev/sda2 /dev/sda2 on / type btrfs (rw,degraded) # btrfs device delete /dev/sda2 / ERROR: error removing the device '/dev/sda2' Do I have to move the data first to /dev/sdb2 (how?) and then delete /dev/sda2? Is there a better way to handle a situation like this? Thanks! -- Regards, Oliver -- 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: migrating drives (device delete)
Hallo Helmut, What tells df: about 300 GByte in use? # df -h | head -n 2 FilesystemSize Used Avail Use% Mounted on /dev/sda2 844G 293G 552G 35% / # btrfs filesystem df / Metadata: total=896.00MB, used=484.77MB Data: total=291.50GB, used=291.15GB System: total=12.00MB, used=28.00KB And I haven't told the system to make a raid0. I've created the first btrfs partition only with mkfs.btrfs /dev/sdxn I also just started with: # mkfs.btrfs /dev/sda2 And I haven't used degraded after balancing the 2 partitions. # mount -o remount /dev/sdb2 / # df -h FilesystemSize Used Avail Use% Mounted on /dev/sda2 844G 293G 552G 35% / none 429M 200K 429M 1% /dev none 435M 0 435M 0% /dev/shm none 435M 48K 435M 1% /var/run none 435M 0 435M 0% /var/lock /dev/sdc1 2.0G 26M 1.9G 2% /boot # btrfs device delete /dev/sda2 / ERROR: error removing the device '/dev/sda2' The balance command may take a long time; I've just seen about 2 days for 1.5 TByte. I balanced immediately after installing the server. It was less than 1GB and took just a couple of seconds. The only idea I have now is to copy everthing to a new fs, chroot into it and update-grub. Is this the best way to go? -- Regards, Oliver -- 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: migrating drives (device delete)
Hallo, Oliver, Du meintest am 10.11.10: # sudo btrfs filesystem show Label: none uuid: cd4fd4c1-0632-4cbe-bf3b-ba7a9acda1e0 Total devices 2 FS bytes used 291.62GB devid2 size 696.77GB used 146.63GB path /dev/sdb2 devid1 size 147.19GB used 146.64GB path /dev/sda2 What tells df: about 300 GByte in use? Now I want to remove the smaller drive: # mount -t btrfs -o remount,degraded /dev/sda2 / # mount | grep /dev/sda2 /dev/sda2 on / type btrfs (rw,degraded) # btrfs device delete /dev/sda2 / ERROR: error removing the device '/dev/sda2' I've tried (with the above device names) btrfs device delete /dev/sda2 / btrfs filesystem balance / Ok - I don't try these commands under / ... And I haven't told the system to make a raid0. I've created the first btrfs partition only with mkfs.btrfs /dev/sdxn And I haven't used degraded after balancing the 2 partitions. The balance command may take a long time; I've just seen about 2 days for 1.5 TByte. As long as balance works it throws messages into /var/log/messages and can be watched with top. When balance has finished: btrfs filesystem show 2/dev/null shouldn't show the deleted partition. Viele Gruesse! Helmut -- 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
btrfs review
Hi list, I spent some time with btrfs testing and reviewing - the document can be found here - http://www.sendspace.com/file/f7u51m (it was too large to attach it here). Please comment it. Thanks,-- 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: labelling
Hallo, Hugo, Du meintest am 10.11.10: findfs LABEL=MM2 shows /dev/sdd2 (the first partition) file -s /dev/sdd2 file -s /dev/sdc3 shows LABEL=MM2 for both partitions (that's not good). No, this is both good and correct. You've got a single filesystem spanning multiple block devices. The *filesystem* possesses the label, and with btrfs you can mount the filesystem using *any* of the block devices that compose it, so both block devices should indeed show the FS label, which is what's happening here. Unmounting /srv/MM and mount LABEL=MM2 /srv/MM doesn't work now, it tries to mount /dev/sdd2 and mourns. mount /dev/sdd2 /srv/MM shows the same error message, What's the error message? What do you get in your kernel logs when you do this? This should work, so there's something wrong, but it's (probably) not to do with disk labels. I'll tell tomorrow; the system is just copying more than 1 TByte ... By the way: df shows about 3.4 TByte usable space (2 TByte and 1.5 TByte), but btrfs filesystem df /srv/MM tells Data: total=2.70TB, used=1.64TB I'm missing about 0.7 TByte! In btrfs filesystem df, the total field is the space that has been allocated to block groups. As more space is needed on the filesystem, the total field will increase to use up the additional raw storage Ok - and many thanks! I'll see tomorrow ... Viele Gruesse! Helmut -- 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: migrating drives (device delete)
This isn't necessarily RAID-0. It's just spread the block group
allocations across both drives. Block groups are 1 GiB in size. if you
use RAID-0, it will allocate block groups in pairs, on different
drives, and stripe the data within the pair (on some much smaller
stripe size). If you use basic allocation as you've got here, it
allocates the block groups one at a time.
Thanks for clarification! This explains why df says there should be
552GB free.
There's no need to mount degraded, as there's no duplication in
your filesystem to degrade. :)
Ok.
Try running the dev del operation under strace (on a freshly
mounted filesystem -- this will probably involve a reboot in your
case), and report back on what the return value from the ioctl
was. That _might_ give us some indication of what's wrong. It would
also be good to know if subsequent attempts to run the dev del
operation return the same error code.
I rebooted the box, here is my output:
# strace btrfs dev del /dev/sda2 /
execve(/sbin/btrfs, [btrfs, dev, del, /dev/sda2, /], [/* 19
vars */]) = 0
brk(0) = 0x902000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f0ebb6cf000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=12540, ...}) = 0
mmap(NULL, 12540, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0ebb6cb000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libuuid.so.1, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\320\25\0\0\0\0\0
\0..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=19008, ...}) = 0
mmap(NULL, 2113920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f0ebb2ac000
mprotect(0x7f0ebb2b, 2093056, PROT_NONE) = 0
mmap(0x7f0ebb4af000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x3000) = 0x7f0ebb4af000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\240\356\1\0\0\0
\0\0..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1572232, ...}) = 0
mmap(NULL, 3680296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f0ebaf29000
mprotect(0x7f0ebb0a3000, 2093056, PROT_NONE) = 0
mmap(0x7f0ebb2a2000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x179000) = 0x7f0ebb2a2000
mmap(0x7f0ebb2a7000, 18472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0x7f0ebb2a7000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f0ebb6ca000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f0ebb6c8000
arch_prctl(ARCH_SET_FS, 0x7f0ebb6c8740) = 0
mprotect(0x7f0ebb2a2000, 16384, PROT_READ) = 0
mprotect(0x7f0ebb4af000, 4096, PROT_READ) = 0
mprotect(0x61c000, 4096, PROT_READ) = 0
mprotect(0x7f0ebb6d1000, 4096, PROT_READ) = 0
munmap(0x7f0ebb6cb000, 12540) = 0
brk(0) = 0x902000
brk(0x923000) = 0x923000
stat(/, {st_mode=S_IFDIR|0755, st_size=244, ...}) = 0
open(/, O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
ioctl(3, 0x5000940b, 0x7fff5385a5f0)= -1 EINVAL (Invalid argument)
write(2, ERROR: error removing the device..., 45ERROR: error removing
the device '/dev/sda2'
) = 45
close(3)= 0
exit_group(21) = ?
I repeated btrfs dev del a couple of times. I it *always* gave a return
code of 21 and ioctl = -1 EINVAL respectively.
# df -h
FilesystemSize Used Avail Use% Mounted on
/dev/sda2 844G 293G 552G 35% /
none 429M 180K 429M 1% /dev
none 435M 0 435M 0% /dev/shm
none 435M 44K 435M 1% /var/run
none 435M 0 435M 0% /var/lock
none 844G 293G 552G 35% /var/lib/ureadahead/debugfs
/dev/sdc1 2.0G 26M 1.9G 2% /boot
--
Regards,
Oliver
--
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: Chunk map/control
On 9/22/2010 4:12 PM, Phillip Susi wrote: Is there currently a way to view and manipulate the chunks? If I understand things correctly, a new fs has a few chunks: 1) System chunk. Contains tree of trees, device tree, chunk tree. 2) Metadata chunk. Contains the directory tree for the default subvol, and any additional subvols/snapshots you create. Directory entries and inodes are in this tree. 3) Data chunk. Files with significant data have blocks allocated from this chunk. The system chunk is always mirrored, even on a single disk. The metadata chunk is mirrored by default, but can be changed with a parameter to mkfs. The data chunk is striped by default, but can be changed via parameter to mkfs. The chunks are all expanded as needed. Is this correct, and is there a way to create a subvol with a new pair of metadata/data chunks and specify how they should be striped or mirrored across what devices? -- 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: labelling
Hallo, Hugo, Du meintest am 10.11.10: findfs LABEL=MM2 shows /dev/sdd2 (the first partition) file -s /dev/sdd2 file -s /dev/sdc3 shows LABEL=MM2 for both partitions [...] Unmounting /srv/MM and mount LABEL=MM2 /srv/MM doesn't work now, it tries to mount /dev/sdd2 and mourns. What's the error message? What do you get in your kernel logs when you do this? This should work, so there's something wrong, but it's (probably) not to do with disk labels. Strange - very strange ... Today in the morning it didn't work. Now it works. I'll see tomorrow if this strange behaviour is related somehow to cold start or some other commands before invoking mount. Viele Gruesse! Helmut -- 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: Update man page for mixed data+metadata option.
On Wed, Nov 10, 2010 at 12:02:18PM -0600, Mitch Harder wrote: Update the mkfs.btrfs man page for the -M option to mix data and metadata chunks. Signed-off-by: Mitch Harder mitch.har...@sabayonlinux.org --- man/mkfs.btrfs.8.in |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index 1e14c6c..c23dddc 100644 --- a/man/mkfs.btrfs.8.in +++ b/man/mkfs.btrfs.8.in @@ -9,6 +9,7 @@ mkfs.btrfs \- create an btrfs filesystem [ \fB \-l\fP\fI leafsize\fP ] [ \fB \-L\fP\fI label\fP ] [ \fB \-m\fP\fI metadata profile\fP ] +[ \fB \-M\fP\fI mixed data+metadata\fP ] [ \fB \-n\fP\fI nodesize\fP ] [ \fB \-s\fP\fI sectorsize\fP ] [ \fB \-h\fP ] @@ -45,6 +46,10 @@ Specify a label for the filesystem. Specify how metadata must be spanned across the devices specified. Valid values are raid0, raid1, raid10 or single. .TP +\fB\-M\fR, \fB\-\-mixed\fR +Mix data and metadata chunks together for more efficient space +utilization. +.TP \fB\-n\fR, \fB\-\-nodesize \fIsize\fR Specify the nodesize. By default the value is set to the pagesize. .TP -- 1.7.2.2 Let's mention that it's for smaller filesystems since it has a significant performance impact when using mixed block groups on larger filesystems. 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
Re: Btrfs-progs: Update man page for mixed data+metadata option.
On Wed, Nov 10, 2010 at 8:10 PM, Josef Bacik jo...@redhat.com wrote: On Wed, Nov 10, 2010 at 12:02:18PM -0600, Mitch Harder wrote: Update the mkfs.btrfs man page for the -M option to mix data and metadata chunks. Signed-off-by: Mitch Harder mitch.har...@sabayonlinux.org --- man/mkfs.btrfs.8.in | 5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index 1e14c6c..c23dddc 100644 --- a/man/mkfs.btrfs.8.in +++ b/man/mkfs.btrfs.8.in @@ -9,6 +9,7 @@ mkfs.btrfs \- create an btrfs filesystem [ \fB \-l\fP\fI leafsize\fP ] [ \fB \-L\fP\fI label\fP ] [ \fB \-m\fP\fI metadata profile\fP ] +[ \fB \-M\fP\fI mixed data+metadata\fP ] [ \fB \-n\fP\fI nodesize\fP ] [ \fB \-s\fP\fI sectorsize\fP ] [ \fB \-h\fP ] @@ -45,6 +46,10 @@ Specify a label for the filesystem. Specify how metadata must be spanned across the devices specified. Valid values are raid0, raid1, raid10 or single. .TP +\fB\-M\fR, \fB\-\-mixed\fR +Mix data and metadata chunks together for more efficient space +utilization. +.TP \fB\-n\fR, \fB\-\-nodesize \fIsize\fR Specify the nodesize. By default the value is set to the pagesize. .TP -- 1.7.2.2 Let's mention that it's for smaller filesystems since it has a significant performance impact when using mixed block groups on larger filesystems. Thanks, Josef OK, how about: Mix data and metadata chunks together for more efficient space utilization, especially on smaller file systems. Incurs a performance penalty. -- 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: Update man page for mixed data+metadata option.
On Wed, Nov 10, 2010 at 9:53 PM, Mitch Harder mitch.har...@sabayonlinux.org wrote: On Wed, Nov 10, 2010 at 8:10 PM, Josef Bacik jo...@redhat.com wrote: On Wed, Nov 10, 2010 at 12:02:18PM -0600, Mitch Harder wrote: Update the mkfs.btrfs man page for the -M option to mix data and metadata chunks. Signed-off-by: Mitch Harder mitch.har...@sabayonlinux.org --- man/mkfs.btrfs.8.in | 5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in index 1e14c6c..c23dddc 100644 --- a/man/mkfs.btrfs.8.in +++ b/man/mkfs.btrfs.8.in @@ -9,6 +9,7 @@ mkfs.btrfs \- create an btrfs filesystem [ \fB \-l\fP\fI leafsize\fP ] [ \fB \-L\fP\fI label\fP ] [ \fB \-m\fP\fI metadata profile\fP ] +[ \fB \-M\fP\fI mixed data+metadata\fP ] [ \fB \-n\fP\fI nodesize\fP ] [ \fB \-s\fP\fI sectorsize\fP ] [ \fB \-h\fP ] @@ -45,6 +46,10 @@ Specify a label for the filesystem. Specify how metadata must be spanned across the devices specified. Valid values are raid0, raid1, raid10 or single. .TP +\fB\-M\fR, \fB\-\-mixed\fR +Mix data and metadata chunks together for more efficient space +utilization. +.TP \fB\-n\fR, \fB\-\-nodesize \fIsize\fR Specify the nodesize. By default the value is set to the pagesize. .TP -- 1.7.2.2 Let's mention that it's for smaller filesystems since it has a significant performance impact when using mixed block groups on larger filesystems. Thanks, Josef OK, how about: Mix data and metadata chunks together for more efficient space utilization, especially on smaller file systems. Incurs a performance penalty. in a previous message, Josef had mentioned it was specifically for 1GB _only_... if so, wording should probably make it perfectly clear that the option is totally inappropriate for _anybody_ unless you meet specific/special criteria. something like DANGER DANGER WILL ROBINSON :-) unless i'm mistaken of course. 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
Re: On Removing BUG_ON macros
On Mon, 2010-11-08 at 23:02 +0800, Ian Kent wrote: On Mon, 2010-11-08 at 09:15 -0500, Josef Bacik wrote: On Mon, Nov 08, 2010 at 10:06:13PM +0800, Ian Kent wrote: On Mon, 2010-11-08 at 07:42 -0500, Josef Bacik wrote: On Mon, Nov 08, 2010 at 10:54:07AM +0800, Ian Kent wrote: On Sun, 2010-11-07 at 09:51 -0500, Josef Bacik wrote: On Sun, Nov 07, 2010 at 04:16:47PM +0900, Yoshinori Sano wrote: This is a question I've posted on the #btrfs IRC channel today. hyperair adviced me to contact with Josef Bacik or Chris Mason. So, I post my question to this maling list. Here are my post on the IRC: Actually, I want to remove BUG_ON(ret) around the Btrfs code. The motivation is to make the Btrfs code more robust. First of all, is this meaningless? For example, there are code like the following: struct btrfs_path *path; path = btrfs_alloc_path(); BUG_ON(!path); This is a frequenty used pattern of current Btrfs code. A btrfs_alloc_path()'s caller has to deal with the allocation failure instead of using BUG_ON. However, (this is what most interesting thing for me) can the caller do any proper error handlings here? I mean, is this a critical situation where we cannot recover from? No we're just lazy ;). Tho making sure the caller can recover from getting -ENOMEM is very important, which is why in some of these paths we just do BUG_ON since fixing the callers is tricky. A good strategy for things like this is to do something like static int foo = 1; path = btrfs_alloc_path(); if (!path || !(foo % 1000)) return -ENOMEM; foo++; Hahaha, I love it. So, return ENOMEM every 1000 times we call the containing function! that way you can catch all the callers and make sure we're handling the error all the way up the chain properly. Thanks, Yeah, I suspect this approach will be a bit confusing though. I believe that it will be more effective, although time consuming, to work through the call tree function by function. Although, as I have said, the problem is working out what needs to be done to recover, rather than working out what the callers are. I'm not at all sure yet but I also suspect that it may not be possible to recover in some cases, which will likely lead to serious rework of some subsystems (but, hey, who am I to say, I really don't have any clue yet). So we talked about this at plumbers. First thing we need is a way to flip the filesystem read only, that way we can deal with the simple corruption cases. Right, yes. And then we can start looking at these harder cases where it's really unclear about how to recover. I have a way to go before I will even understand these cases. Thankfully because we're COW we really shouldn't have any cases that we have to unwind anything, we just fail the operation and go on our happy merry way. The only tricky thing is where we get ENOMEM when say inserting the metadata for data after writing out the data, since that will leave data just sitting around. Probably should look at what NFS does with dirty pages when the server hangs up. OK, that's a though for me to focus on while I'm trying to work out what's going on ... mmm. Indeed, a large proportion of these are handling ENOMEM. I somehow suspect your heavily focused on disk io itself when I'm still back thinking about house keeping of operations, in the process of being queued and those currently being processed, the later being the difficult case. But I'll eventually get to worrying about io as part of that process. It's also worth mentioning that my scope is also quite narrow at this stage, focusing largely on the transaction subsystem, although that tends to pull in a fair amount of other code too. So the transaction stuff should be relatively simple since we shouldn't have too much to clean up if the transaction fails to allocate. Maybe point out some places where you are having trouble and I can frame up what we'd want to do to give you an idea of where to go? Thanks, Thanks, I will when I have something to discuss or maybe I'll start with the couple I have, when I get a chance to get back to it anyway. How about we discuss this patch to start with? The places where I have put /* TODO: What to do here? */ are the places where I couldn't work out what to do or if some sort of recovery is needed or what effect a failure might have on continued operations. btrfs - resolve bug_on()s in btrfs_record_root_in_trans() From: Ian Kent
Re: NFS support
Thank you, I will choose another one. 2010/11/10, Josef Bacik jo...@redhat.com: On Wed, Nov 10, 2010 at 12:53:59PM +0800, Wenyi Liu wrote: Hi All: I found the project ideas about NFS support in btrfs wiki. But, I have long time to disconnect to the btrfs mail list. Can you give me the process of the support? Thanks!! NFS support already is there. 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
