Porting BTRFS to user space

Porting BTRFS to user space

[인정식]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=euc-kr, Size: 714 bytes --]

Hello BTRFS developers,

I am requesting your opion.

I am planning to design and implement DFS version of BTRFS.
Roughly it will be done by
    1. Extending current DeviceID to NodeID:DeviceID to support multi-node, and
    2. Implementing inter-node data and meta-data access over TCP.
Do you think it would be feasible?

For development, I would like to port the kernel code to user space.
I could continue to run in user mode or be ported back to kernel space.
But I don't know how can I start to porting the kernel code to user space.
Is there anyone who can help?

Thanks,
Jeongsikÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Porting BTRFS to user space

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

On 2015-04-06 21:28, 인정식 wrote:
> Hello BTRFS developers,
> 
> I am requesting your opion.
> 
> I am planning to design and implement DFS version of BTRFS.
> Roughly it will be done by
>     1. Extending current DeviceID to NodeID:DeviceID to support multi-node, and
>     2. Implementing inter-node data and meta-data access over TCP.
> Do you think it would be feasible?
> 
> For development, I would like to port the kernel code to user space.
> I could continue to run in user mode or be ported back to kernel space.
> But I don't know how can I start to porting the kernel code to user space.
> Is there anyone who can help?
> 
> Thanks,
> JeongsikN떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{켷雹�)�鍊w*\x1fjgП�\x1e텎쉸듶줷/곴�z받뻿�2듷솳鈺�&�)傘첺뛴\x7f�\x1e췍쳺�h�\x0f�j:+v돣둾�明
> 
Personally, my suggestion would be to start with a port to FUSE, and
then start implementing your modifications off of that.  That said, much
of the code should already be available in userspace through libbtrfs,
which is packaged with btrfs-progs.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

Re: Re: Porting BTRFS to user space

[인정식]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=euc-kr, Size: 1807 bytes --]

Thank you for the information.
I just found that btrfs-progs includes several files that seem modified from btrfs kernel source.
I am not sure exactly what they are.
Web pages say libbtrfs is to provide interface for apps that use btrfs.
Why should there be duplicated codes between kernel and user space?
Is it an on-going effort to port whole btrfs to user space?

Could you lead me to some more information about libbtrfs or how to port btrfs to user space?

Thank you,
Jeongsik


------- Original Message -------
Sender : Austin S Hemmelgarn<ahferroin7@gmail.com> 
Date   : 2015-04-08 02:50 (GMT+09:00)
Title  : Re: Porting BTRFS to user space

On 2015-04-06 21:28, ÀÎÁ¤½Ä wrote:
> Hello BTRFS developers,
> 
> I am requesting your opion.
> 
> I am planning to design and implement DFS version of BTRFS.
> Roughly it will be done by
>     1. Extending current DeviceID to NodeID:DeviceID to support multi-node, and
>     2. Implementing inter-node data and meta-data access over TCP.
> Do you think it would be feasible?
> 
> For development, I would like to port the kernel code to user space.
> It could continue to run in user mode or be ported back to kernel space.
> But I don't know how can I start to porting the kernel code to user space.
> Is there anyone who can help?
> 
> Thanks,
> JeongsikN?²æ?r?yúè?b?¬¶Ç§v?^?)Þº{.n?+??{?Úß?)?æèw*\x1fjg¬±?\x1e????/??z¹Þ??2??è­?&?)ß¡?¶Ú\x7f?\x1e???h?\x0f?j:+v???Ù¥
> 
Personally, my suggestion would be to start with a port to FUSE, and
then start implementing your modifications off of that.  That said, much
of the code should already be available in userspace through libbtrfs,
which is packaged with btrfs-progs.

<p>&nbsp;</p><p>&nbsp;</p>ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Porting BTRFS to user space

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

On 2015-04-07 19:57, 인정식 wrote:
> Thank you for the information.
> I just found that btrfs-progs includes several files that seem modified from btrfs kernel source.
> I am not sure exactly what they are.
> Web pages say libbtrfs is to provide interface for apps that use btrfs.
> Why should there be duplicated codes between kernel and user space?
> Is it an on-going effort to port whole btrfs to user space?
> 
> Could you lead me to some more information about libbtrfs or how to port btrfs to user space?
> 
> Thank you,
> Jeongsik
> 
> 
As far as I understand it, the intent is to allow things like btrfs
check and btrfs restore to still work even if the kernel doesn't have
btrfs support.  From what I can tell, you are the first person to
actually be serious about getting BTRFS running in userspace, so there
probably isn't much BTRFS specific literature out there.

I would, however suggest looking at the FUSE drivers for ext4 and ZFS,
as those are both ported from kernel space, and should give some good
examples of where to start.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

Re: Re: Porting BTRFS to user space

[인정식]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=euc-kr, Size: 2090 bytes --]

Thank you for the advise.
I am still wonder why there are same-name files in btrfs(kernel source) and btrfs-progs.
They are quite many as follows.
    backref.{c, h}
    ctree.{c, h}
    dir-item.c
    disk-io.{c, h}
    extent_io.{c, h}
    extent-tree.c
    file.c
    file-item.c
    free-space-cashe.{c, h}
    hash.h
    inode.c
    inode-item.c
    inode-map.c
    print-tree.{c, h}
    props.{c, h}
    qgroup.{c, h}
    root-tree.c
    send.h
    ulist.{c, h}
    uuid-tree.c
    volumes.{c, h}

It seems btrfs-progs files have been ported from kernel files.
Are they the result of efforts to port btrfs from kernel to user space?
Or at least can I utilize the them so that I have to only port the remaining files?

------- Original Message -------
Sender : Austin S Hemmelgarn<ahferroin7@gmail.com> 
Date   : 2015-04-08 20:37 (GMT+09:00)
Title  : Re: Porting BTRFS to user space

On 2015-04-07 19:57, ÀÎÁ¤½Ä wrote:
> Thank you for the information.
> I just found that btrfs-progs includes several files that seem modified from btrfs kernel source.
> I am not sure exactly what they are.
> Web pages say libbtrfs is to provide interface for apps that use btrfs.
> Why should there be duplicated codes between kernel and user space?
> Is it an on-going effort to port whole btrfs to user space?
> 
> Could you lead me to some more information about libbtrfs or how to port btrfs to user space?
> 
> Thank you,
> Jeongsik
> 
> 
As far as I understand it, the intent is to allow things like btrfs
check and btrfs restore to still work even if the kernel doesn't have
btrfs support.  From what I can tell, you are the first person to
actually be serious about getting BTRFS running in userspace, so there
probably isn't much BTRFS specific literature out there.

I would, however suggest looking at the FUSE drivers for ext4 and ZFS,
as those are both ported from kernel space, and should give some good
examples of where to start.

<p>&nbsp;</p><p>&nbsp;</p>ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Re: Porting BTRFS to user space

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 4225 bytes --]

On Wed, Apr 08, 2015 at 12:03:29PM +0000, 인정식 wrote:
> Thank you for the advise.
> I am still wonder why there are same-name files in btrfs(kernel source) and btrfs-progs.
> They are quite many as follows.
>     backref.{c, h}
>     ctree.{c, h}
>     dir-item.c
>     disk-io.{c, h}
>     extent_io.{c, h}
>     extent-tree.c
>     file.c
>     file-item.c
>     free-space-cashe.{c, h}
>     hash.h
>     inode.c
>     inode-item.c
>     inode-map.c
>     print-tree.{c, h}
>     props.{c, h}
>     qgroup.{c, h}
>     root-tree.c
>     send.h
>     ulist.{c, h}
>     uuid-tree.c
>     volumes.{c, h}
> 
> It seems btrfs-progs files have been ported from kernel files.
> Are they the result of efforts to port btrfs from kernel to user space?

   Kind of. They were copied from kernel space some time ago, but have
diverged from that point significantly since. There's all kinds of
extra flags and options in the userspace code that allow it to bypass
particular kinds of checks for the recovery tools. The kernel
implementation will have moved on in different ways since, as well.

> Or at least can I utilize the them so that I have to only port the remaining files?

   You'll probably find that a lot of the remainder are to do with the
interface to the block layer, which I think (without actually knowing
much about FUSE) you won't need to do much of.

   I have to say, I'm somewhat more concerned about your distributed
systems design. You haven't mentioned anywhere any of the design
features that you would have to think about for a distributed
filesystem. For example, how do you handle concurrent access from
different machines, node failures, network failures, caching of
data/metadata, synchronisation of write followed by read (possibly by
a different node)?

   I would suggest that you're better off spending your effort on
those issues in your userspace distributed filesystem, and simply
using btrfs itself as a backing store. This gives you a useful
separation between the relatively simple underlying "write some bytes
to permanent storage" layer and the horrible, nasty, complicated
"manage a distributed data store in a usable way" layer on top of it.

   It's noticeable that pretty much all of the network and distributed
filesystems that I'm aware of have this kind of architecture: an
ordinary boring non-distributed filestore running on each storage
node, and a networking, metadata, caching and management layer on top
of that to deal with the distributed parts. (NFS, Ceph, Gluster
certainly work this way. I would be surprised if any of the others out
there at the moment didn't work like that).

   Hugo.

> ------- Original Message -------
> Sender : Austin S Hemmelgarn<ahferroin7@gmail.com> 
> Date   : 2015-04-08 20:37 (GMT+09:00)
> Title  : Re: Porting BTRFS to user space
> 
> On 2015-04-07 19:57, 인정식 wrote:
> > Thank you for the information.
> > I just found that btrfs-progs includes several files that seem modified from btrfs kernel source.
> > I am not sure exactly what they are.
> > Web pages say libbtrfs is to provide interface for apps that use btrfs.
> > Why should there be duplicated codes between kernel and user space?
> > Is it an on-going effort to port whole btrfs to user space?
> > 
> > Could you lead me to some more information about libbtrfs or how to port btrfs to user space?
> > 
> > Thank you,
> > Jeongsik
> > 
> > 
> As far as I understand it, the intent is to allow things like btrfs
> check and btrfs restore to still work even if the kernel doesn't have
> btrfs support.  From what I can tell, you are the first person to
> actually be serious about getting BTRFS running in userspace, so there
> probably isn't much BTRFS specific literature out there.
> 
> I would, however suggest looking at the FUSE drivers for ext4 and ZFS,
> as those are both ported from kernel space, and should give some good
> examples of where to start.
> 
> <p>&nbsp;</p><p>&nbsp;</p>

-- 
Hugo Mills             | "I lost my leg in 1942. Some bastard stole it in a
hugo@... carfax.org.uk | pub in Pimlico."
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Porting BTRFS to user space

[Chris Samuel]

On Wed, 8 Apr 2015 12:27:57 PM Hugo Mills wrote:

> (NFS, Ceph, Gluster certainly work this way. I would be surprised if
> any of the others out there at the moment didn't work like that).

GPFS has its own underlying filesystem format, you can upgrade the
format on the fly with mmchfs once all your GPFS nodes are at the
same minimum version.

Painful IBM URL follows:

http://www-01.ibm.com/support/knowledgecenter/#!/SSFKCN_4.1.0/com.ibm.cluster.gpfs.v4r1.gpfs100.doc/bl1adm_fsmigissues.htm

All the best,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

Re: Porting BTRFS to user space

[Stef Bon]

Hi all,

maybe interesting to know,

I'm working on a backup service, which uses btrfs for making snapshots.
The user can assign a folder for backup very easy, and create "rules" per backup
of what to backup. Right now it works with assigning mimetypes to a backup:
the files ot these mimetypes will be watched and made a backup of.

To show the backup of a file and all the versions available it uses FUSE.
To keep track of the different versions sqlite is used.

I do not have a project page yet, but a message at the kde forum:

https://forum.kde.org/viewtopic.php?f=223&t=125124

and I'm planning to give a presentation at the openSuse meeting at Den
Hage in may.

This FUSE fs is totally different from what you're looking for, but
still maybe interesting.

Stef