On Wed, Dec 08, 2010 at 09:41:33PM -0700, Andreas Dilger wrote:
On 2010-12-08, at 16:07, Neil Brown wrote:
On Mon, 6 Dec 2010 11:48:45 -0500 J. Bruce Fields bfie...@redhat.com
wrote:
On Fri, Dec 03, 2010 at 04:01:44PM -0700, Andreas Dilger wrote:
Any chance we can add a -get_fsid(sb,
On 2010-12-07, at 10:02, Trond Myklebust wrote:
On Tue, 2010-12-07 at 17:51 +0100, Christoph Hellwig wrote:
It's just as stable as a real dev_t in the times of hotplug and udev.
As long as you don't touch anything including not upgrading the kernel
it's remain stable, otherwise it will break.
On Wed, Dec 08, 2010 at 10:16:29AM -0700, Andreas Dilger wrote:
On 2010-12-07, at 10:02, Trond Myklebust wrote:
On Tue, 2010-12-07 at 17:51 +0100, Christoph Hellwig wrote:
It's just as stable as a real dev_t in the times of hotplug and udev.
As long as you don't touch anything including
On 2010-12-06, at 09:48, J. Bruce Fields wrote:
On Fri, Dec 03, 2010 at 04:01:44PM -0700, Andreas Dilger wrote:
Any chance we can add a -get_fsid(sb, inode) method to
export_operations (or something simiar), that allows the filesystem to
generate an FSID based on the volume and inode that is
On Mon, 6 Dec 2010 11:48:45 -0500 J. Bruce Fields bfie...@redhat.com
wrote:
On Fri, Dec 03, 2010 at 04:01:44PM -0700, Andreas Dilger wrote:
On 2010-12-03, at 15:45, J. Bruce Fields wrote:
We're using statfs64.fs_fsid for this; I believe that's both stable
across reboots and distinguishes
On 2010-12-08, at 16:07, Neil Brown wrote:
On Mon, 6 Dec 2010 11:48:45 -0500 J. Bruce Fields bfie...@redhat.com
wrote:
On Fri, Dec 03, 2010 at 04:01:44PM -0700, Andreas Dilger wrote:
Any chance we can add a -get_fsid(sb, inode) method to
export_operations (or something simiar), that allows
=== What do subvolumes look like? ===
All the user sees are directories. They act like any other directory acts,
with
a few exceptions
1) You cannot hardlink between subvolumes. This is because subvolumes have
their own inode numbers and such, think of them as seperate mounts in this
On Sat, Dec 04, 2010 at 09:27:56AM +1100, Dave Chinner wrote:
A property of NFS fileshandles is that they must be stable across
server reboots. Is this anon dev_t used as part of the NFS
filehandle and if so how can you guarantee that it is stable?
It's just as stable as a real dev_t in the
On Fri, Dec 03, 2010 at 05:45:26PM -0500, J. Bruce Fields wrote:
We're using statfs64.fs_fsid for this; I believe that's both stable
across reboots and distinguishes between subvolumes, so that's OK.
It's a field that doesn't have any useful specification and basically
contains random garbage
On Tue, 2010-12-07 at 17:51 +0100, Christoph Hellwig wrote:
On Sat, Dec 04, 2010 at 09:27:56AM +1100, Dave Chinner wrote:
A property of NFS fileshandles is that they must be stable across
server reboots. Is this anon dev_t used as part of the NFS
filehandle and if so how can you guarantee
On Tue, Dec 07, 2010 at 05:52:13PM +0100, hch wrote:
On Fri, Dec 03, 2010 at 05:45:26PM -0500, J. Bruce Fields wrote:
We're using statfs64.fs_fsid for this; I believe that's both stable
across reboots and distinguishes between subvolumes, so that's OK.
It's a field that doesn't have any
2010/12/2 David Pottage da...@electric-spoon.com:
Therefore I think it is a bad idea if potentially different files on btrfs
can have the same inode number. It will break all sorts of tools.
Instead of maintaining a big complicated reference count of used inode
numbers, could btrfs use bit
On Thu, Dec 02, 2010 at 11:25:01PM -0500, Chris Ball wrote:
Hi Josef,
1) Scrap the 256 inode number thing. Instead we'll just put a
flag in the inode to say Hey, I'm a subvolume and then we can
do all of the appropriate magic that way. This unfortunately
will be an
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have complained about how BTRFS deals with subvolumes recently,
specifically the fact that they all have the same inode number, and there's no
discrete seperation from one subvolume to another. Christoph
On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
So now that I've actually looked at everything, it looks like the semantics
are
all right for subvolumes
1) readdir - we return the root id in d_ino, which is unique across the fs
Though Michael Vrable pointed out an apparent
On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have complained about how BTRFS deals with subvolumes
recently,
specifically the fact that they all have the same inode number, and there's
Excerpts from Dave Chinner's message of 2010-12-03 17:27:56 -0500:
On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have complained about how BTRFS deals with subvolumes
recently,
On Fri, Dec 03, 2010 at 05:29:24PM -0500, Chris Mason wrote:
Excerpts from Dave Chinner's message of 2010-12-03 17:27:56 -0500:
On Fri, Dec 03, 2010 at 04:45:27PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have
On 2010-12-03, at 15:45, J. Bruce Fields wrote:
We're using statfs64.fs_fsid for this; I believe that's both stable
across reboots and distinguishes between subvolumes, so that's OK.
(That said, since fs_fsid doesn't work for other filesystems, we depend
on an explicit check for a filesystem
Josef Bacik wrote:
This is a huge topic in and of itself, but Christoph mentioned wanting to have
an idea of what we wanted to do with it, so I'm putting it here. There are
really 2 things here
1) Limiting the size of subvolumes. This is really easy for us, just create a
subvolume and
Josef Bacik wrote:
1) Scrap the 256 inode number thing. Instead we'll just put a flag in the
inode
to say Hey, I'm a subvolume and then we can do all of the appropriate magic
that way. This unfortunately will be an incompatible format change, but the
sooner we get this adressed the
Excerpts from Arne Jansen's message of 2010-12-02 04:49:39 -0500:
Josef Bacik wrote:
1) Scrap the 256 inode number thing. Instead we'll just put a flag in the
inode
to say Hey, I'm a subvolume and then we can do all of the appropriate
magic
that way. This unfortunately will be an
On 02/12/10 16:11, Chris Mason wrote:
Excerpts from Arne Jansen's message of 2010-12-02 04:49:39 -0500:
Josef Bacik wrote:
1) Scrap the 256 inode number thing. Instead we'll just put a flag in the inode
to say Hey, I'm a subvolume and then we can do all of the appropriate magic
that
On 12/02/2010 04:49 AM, Arne Jansen wrote:
What about the alternative and allocating inode numbers globally? The only
problem would be with snapshots as they share the inum with the source, but
one could just remap inode numbers in snapshots by sparing some bits at the
top of this 64 bit field.
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
1) Users need to be able to create their own subvolumes. The permission
semantics will be absolutely the same as creating directories, so I don't
think
this is too tricky. We want this because you can only take snapshots of
On Wed, Dec 1, 2010 at 8:21 AM, Josef Bacik jo...@redhat.com wrote:
=== How do we want subvolumes to work from a user perspective? ===
1) Users need to be able to create their own subvolumes. The permission
semantics will be absolutely the same as creating directories, so I don't
think
Excerpts from Josef Bacik's message of 2010-12-01 09:21:36 -0500:
Hello,
Various people have complained about how BTRFS deals with subvolumes recently,
specifically the fact that they all have the same inode number, and there's no
discrete seperation from one subvolume to another. Christoph
Excerpts from C Anthony Risinger's message of 2010-12-01 09:51:55 -0500:
On Wed, Dec 1, 2010 at 8:21 AM, Josef Bacik jo...@redhat.com wrote:
=== How do we want subvolumes to work from a user perspective? ===
1) Users need to be able to create their own subvolumes. The permission
On Wed, Dec 1, 2010 at 10:01 AM, Chris Mason chris.ma...@oracle.com wrote:
Excerpts from C Anthony Risinger's message of 2010-12-01 09:51:55 -0500:
On Wed, Dec 1, 2010 at 8:21 AM, Josef Bacik jo...@redhat.com wrote:
=== How do we want subvolumes to work from a user perspective? ===
1)
On Wed, Dec 01, 2010 at 11:01:37AM -0500, Chris Mason wrote:
Excerpts from C Anthony Risinger's message of 2010-12-01 09:51:55 -0500:
On Wed, Dec 1, 2010 at 8:21 AM, Josef Bacik jo...@redhat.com wrote:
=== How do we want subvolumes to work from a user perspective? ===
1) Users need
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
=== Quotas ===
This is a huge topic in and of itself, but Christoph mentioned wanting to have
an idea of what we wanted to do with it, so I'm putting it here. There are
really 2 things here
1) Limiting the size of subvolumes.
On Wed, Dec 1, 2010 at 10:38 AM, Hugo Mills hugo-l...@carfax.org.uk wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
=== Quotas ===
This is a huge topic in and of itself, but Christoph mentioned wanting to
have
an idea of what we wanted to do with it, so I'm putting it
On Wed, Dec 01, 2010 at 04:38:00PM +, Hugo Mills wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
=== Quotas ===
This is a huge topic in and of itself, but Christoph mentioned wanting to
have
an idea of what we wanted to do with it, so I'm putting it here.
On Wed, Dec 01, 2010 at 04:38:00PM +, Hugo Mills wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
=== Quotas ===
This is a huge topic in and of itself, but Christoph mentioned wanting to
have
an idea of what we wanted to do with it, so I'm putting it here.
On Wed, Dec 01, 2010 at 07:33:39PM +0100, Goffredo Baroncelli wrote:
On Wednesday, 01 December, 2010, Josef Bacik wrote:
Hello,
Hi Josef
=== What are subvolumes? ===
They are just another tree. In BTRFS we have various b-trees to describe
the
filesystem. A few of them
On Wed, Dec 1, 2010 at 12:36 PM, Josef Bacik jo...@redhat.com wrote:
On Wed, Dec 01, 2010 at 07:33:39PM +0100, Goffredo Baroncelli wrote:
Another point that I want like to discuss is how manage the pivoting
between
the subvolumes. One of the most beautiful feature of btrfs is the snapshot
On Wed, Dec 1, 2010 at 12:48 PM, C Anthony Risinger anth...@extof.me wrote:
On Wed, Dec 1, 2010 at 12:36 PM, Josef Bacik jo...@redhat.com wrote:
On Wed, Dec 01, 2010 at 07:33:39PM +0100, Goffredo Baroncelli wrote:
Another point that I want like to discuss is how manage the pivoting
between
On Wednesday, 01 December, 2010, you (C Anthony Risinger) wrote:
[...]
i forgot to mention, but a quick 'n dirty solution would be to simply
not enable users to do this by accident. mkfs.btrfs could create a
new subvol, then mark it as default... this way the user has to
manually mount with
On Wed, Dec 01, 2010 at 12:38:30PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 04:38:00PM +, Hugo Mills wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
=== Quotas ===
This is a huge topic in and of itself, but Christoph mentioned wanting to
have
an
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have complained about how BTRFS deals with subvolumes recently,
specifically the fact that they all have the same inode number, and there's no
discrete seperation from one subvolume to another. Christoph
On Wed, Dec 01, 2010 at 02:44:04PM -0500, J. Bruce Fields wrote:
On Wed, Dec 01, 2010 at 09:21:36AM -0500, Josef Bacik wrote:
Hello,
Various people have complained about how BTRFS deals with subvolumes
recently,
specifically the fact that they all have the same inode number, and
On Wed, Dec 01, 2010 at 02:54:33PM -0500, Josef Bacik wrote:
Oh well crud, I was hoping that I could leave the inode numbers as 256 for
everything, but I forgot about readdir. So the inode item in the parent would
have to have a unique inode number that would get spit out in readdir, but
On Wed, 1 Dec 2010 09:21:36 -0500
Josef Bacik jo...@redhat.com wrote:
There is one tricky thing. When you create a subvolume, the directory inode
that is created in the parent subvolume has the inode number of 256. So if
you
have a bunch of subvolumes in the same parent subvolume, you are
On Wed, Dec 01, 2010 at 03:00:08PM -0500, J. Bruce Fields wrote:
On Wed, Dec 01, 2010 at 02:54:33PM -0500, Josef Bacik wrote:
Oh well crud, I was hoping that I could leave the inode numbers as 256 for
everything, but I forgot about readdir. So the inode item in the parent
would
have to
On Wed, Dec 01, 2010 at 03:09:52PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 03:00:08PM -0500, J. Bruce Fields wrote:
On Wed, Dec 01, 2010 at 02:54:33PM -0500, Josef Bacik wrote:
Oh well crud, I was hoping that I could leave the inode numbers as 256 for
everything, but I forgot
On Wed, Dec 1, 2010 at 11:35 AM, Hugo Mills hugo-l...@carfax.org.uk wrote:
On Wed, Dec 01, 2010 at 12:38:30PM -0500, Josef Bacik wrote:
If you delete your subvolume A, like use the btrfs tool to delete it, you
will
only be stuck with what you changed in snapshot B. So if you only changed
On Wed, 1 Dec 2010 21:46:03 +0100
Goffredo Baroncelli kreij...@libero.it wrote:
On Wednesday, 01 December, 2010, Jeff Layton wrote:
A more common use case than CIFS or samba is going to be things like
backup programs. They commonly look at inode numbers in order to
identify hardlinks and
On Wed, Dec 01, 2010 at 12:24:28PM -0800, Freddie Cash wrote:
On Wed, Dec 1, 2010 at 11:35 AM, Hugo Mills hugo-l...@carfax.org.uk wrote:
The idea is you are only charged for what blocks
you have on the disk. Thanks,
My point was that it's perfectly possible to have blocks on the
On Wed, Dec 1, 2010 at 1:28 PM, Hugo Mills hugo-l...@carfax.org.uk wrote:
On Wed, Dec 01, 2010 at 12:24:28PM -0800, Freddie Cash wrote:
On Wed, Dec 1, 2010 at 11:35 AM, Hugo Mills hugo-l...@carfax.org.uk wrote:
The idea is you are only charged for what blocks
you have on the disk. Thanks,
On Wed, Dec 01, 2010 at 03:09:52PM -0500, Josef Bacik wrote:
On Wed, Dec 01, 2010 at 03:00:08PM -0500, J. Bruce Fields wrote:
I think you're already fine:
# mkdir TMP
# dd if=/dev/zero of=TMP-image bs=1M count=512
# mkfs.btrfs TMP-image
# mount -oloop TMP-image
On Wed, Dec 1, 2010 at 3:32 PM, Freddie Cash fjwc...@gmail.com wrote:
On Wed, Dec 1, 2010 at 1:28 PM, Hugo Mills hugo-l...@carfax.org.uk wrote:
On Wed, Dec 01, 2010 at 12:24:28PM -0800, Freddie Cash wrote:
On Wed, Dec 1, 2010 at 11:35 AM, Hugo Mills hugo-l...@carfax.org.uk wrote:
The idea is
51 matches
Mail list logo
