Linux Btrfs filesystem development
 help / color / mirror / Atom feed
* snapshots changed behavior
@ 2011-10-21 16:31 Jim
  2011-10-21 17:53 ` Goffredo Baroncelli
  0 siblings, 1 reply; 5+ messages in thread
From: Jim @ 2011-10-21 16:31 UTC (permalink / raw)
  To: linux-btrfs

Good afternoon btrfs list,
about a month ago, when testing btrfs, I could create a snapshot with 
btrfs snap create and be able to drill down in the snapshot to find 
subvols and files below the snapshot level.  I currently need to use 
btrfsctl -s to create snapshots and can no longer drill down through 
subvols in them.  An example would be a file tree of /btrfs (subvol)
/data (subvol) /sites (subvol) /0000 (directory) /files-in-dir.  If I 
snapshot /btrfs/data I can open data and see /sites but can see nothing 
below /sites.  However, if I snap /btrfs/data/sites I can drill down 
through all lower directories and files.  In my past tests I was able to 
drill all the way down from the /btrfs/data snap.  Also, in the past, a 
snap was definitely a sparse file and was able to easily be moved, moved 
back, remounted and used.  Currently, the useful file /btrfs/data/sites 
contains 5GB of data and both shows and moves as 5GB of data, not like a 
sparse file.  Am I misusing the filesystem, or improperly using the 
commands?  Or have changes been made to the functionality which I 
missed?  Sorry to take your time on such a simple matter, but I need to 
understand how to best use the filesystem.  Thanks very much for your 
advice.
Jim Maloney

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: snapshots changed behavior
  2011-10-21 16:31 snapshots changed behavior Jim
@ 2011-10-21 17:53 ` Goffredo Baroncelli
  2011-10-21 18:29   ` Jim
  0 siblings, 1 reply; 5+ messages in thread
From: Goffredo Baroncelli @ 2011-10-21 17:53 UTC (permalink / raw)
  To: Jim; +Cc: linux-btrfs

On Friday, 21 October, 2011 12:31:34 Jim wrote:
> Good afternoon btrfs list,

Hi Jim

> about a month ago, when testing btrfs, I could create a snapshot with
> btrfs snap create and be able to drill down in the snapshot to find
> subvols and files below the snapshot level.  I currently need to use
> btrfsctl -s to create snapshots and can no longer drill down through
> subvols in them.  An example would be a file tree of /btrfs (subvol)
> /data (subvol) /sites (subvol) /0000 (directory) /files-in-dir.  If I
> snapshot /btrfs/data I can open data and see /sites but can see nothing
> below /sites.  However, if I snap /btrfs/data/sites I can drill down
> through all lower directories and files.  In my past tests I was able to
> drill all the way down from the /btrfs/data snap.  

I am quite sure that the snapshot is NOT recursive. If a subvolume contains 
another subvolume, and you snapshot the former, the new subvolume shall not 
contain the "child" subvolume.

>From what you report, it seems that /sites was a directory and not a snapshot.

Pay attention that btrfsctl -s allow to take as source a directory. In this 
case this program snapshot the subvolume which contains the subdirectory 
passed as argument. 
Instead the btrfs tool checked if the source is a subvolume. If not it raises 
an error.

I say so because the btrfctl behaviour confused a lot of people.

In any case btrfs was never been capable to snapshot a directory.

> Also, in the past, a
> snap was definitely a sparse file and was able to easily be moved, moved
> back, remounted and used.  Currently, the useful file /btrfs/data/sites
> contains 5GB of data and both shows and moves as 5GB of data, not like a
> sparse file.  Am I misusing the filesystem, or improperly using the
> commands?  Or have changes been made to the functionality which I
> missed?  

It is not allowed to move files between subvolume. The mv command in this case 
copies the files and removes the original ones.

>From what you wrote it seems that (for mistake) you thought that a directory 
was a subvolume.

> Sorry to take your time on such a simple matter, but I need to
> understand how to best use the filesystem.  Thanks very much for your
> advice.
> Jim Maloney
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: snapshots changed behavior
  2011-10-21 17:53 ` Goffredo Baroncelli
@ 2011-10-21 18:29   ` Jim
  2011-10-21 18:43     ` Goffredo Baroncelli
  0 siblings, 1 reply; 5+ messages in thread
From: Jim @ 2011-10-21 18:29 UTC (permalink / raw)
  To: Goffredo Baroncelli; +Cc: linux-btrfs

Goffredo,
Thank you very much for your reply.  That was the information I needed 
to understand the behavior I was observing.  Just to be sure that I 
understand correctly, you wrote:

I am quite sure that the snapshot is NOT recursive. If a subvolume contains
another subvolume, and you snapshot the former, the new subvolume shall not
contain the "child" subvolume.

when I snapshot /data, a subvolume I can see (but not enter) the 
subvolume /sites below it.  When I snapshot subvolume /sites I can see 
and navigate through all directories (not subvolumes) below it.  I am 
assuming that this is expected behavior.  Thanks again for taking the 
time to help me here.
Jim

On 10/21/2011 01:53 PM, Goffredo Baroncelli wrote:
> On Friday, 21 October, 2011 12:31:34 Jim wrote:
>> Good afternoon btrfs list,
> Hi Jim
>
>> about a month ago, when testing btrfs, I could create a snapshot with
>> btrfs snap create and be able to drill down in the snapshot to find
>> subvols and files below the snapshot level.  I currently need to use
>> btrfsctl -s to create snapshots and can no longer drill down through
>> subvols in them.  An example would be a file tree of /btrfs (subvol)
>> /data (subvol) /sites (subvol) /0000 (directory) /files-in-dir.  If I
>> snapshot /btrfs/data I can open data and see /sites but can see nothing
>> below /sites.  However, if I snap /btrfs/data/sites I can drill down
>> through all lower directories and files.  In my past tests I was able to
>> drill all the way down from the /btrfs/data snap.
> I am quite sure that the snapshot is NOT recursive. If a subvolume contains
> another subvolume, and you snapshot the former, the new subvolume shall not
> contain the "child" subvolume.
>
>  From what you report, it seems that /sites was a directory and not a snapshot.
>
> Pay attention that btrfsctl -s allow to take as source a directory. In this
> case this program snapshot the subvolume which contains the subdirectory
> passed as argument.
> Instead the btrfs tool checked if the source is a subvolume. If not it raises
> an error.
>
> I say so because the btrfctl behaviour confused a lot of people.
>
> In any case btrfs was never been capable to snapshot a directory.
>
>> Also, in the past, a
>> snap was definitely a sparse file and was able to easily be moved, moved
>> back, remounted and used.  Currently, the useful file /btrfs/data/sites
>> contains 5GB of data and both shows and moves as 5GB of data, not like a
>> sparse file.  Am I misusing the filesystem, or improperly using the
>> commands?  Or have changes been made to the functionality which I
>> missed?
> It is not allowed to move files between subvolume. The mv command in this case
> copies the files and removes the original ones.
>
>  From what you wrote it seems that (for mistake) you thought that a directory
> was a subvolume.
>
>> Sorry to take your time on such a simple matter, but I need to
>> understand how to best use the filesystem.  Thanks very much for your
>> advice.
>> Jim Maloney
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: snapshots changed behavior
  2011-10-21 18:29   ` Jim
@ 2011-10-21 18:43     ` Goffredo Baroncelli
  2011-10-21 18:50       ` Jim
  0 siblings, 1 reply; 5+ messages in thread
From: Goffredo Baroncelli @ 2011-10-21 18:43 UTC (permalink / raw)
  To: Jim; +Cc: linux-btrfs

On Friday, 21 October, 2011 14:29:11 Jim wrote:
> Goffredo,
> Thank you very much for your reply.  That was the information I needed 
> to understand the behavior I was observing.  Just to be sure that I 
> understand correctly, you wrote:
> 
> I am quite sure that the snapshot is NOT recursive. If a subvolume contains
> another subvolume, and you snapshot the former, the new subvolume shall not
> contain the "child" subvolume.
> 
> when I snapshot /data, a subvolume I can see (but not enter) the 
> subvolume /sites below it.  
You should be able to enter; however in the latter case /sites is a 
subdirectory instead of a subvolume.

To check if a directory is a subvolume, you can see its inode number. If the 
inode number is 256, then the directory is a entry point of a subvolume.


See this example


# btrfs subvolume create a
Create subvolume './a'
# btrfs subvolume create a/b
Create subvolume 'a/b'
# echo 123 >a/b/c
# btrfs subvolume snapshot a d
Create a snapshot of 'a' in './d'
# ls -li d/
total 0
2 drwxr-xr-x 1 root root 0 Oct 21 20:41 b

d/b is a directory, because its inode number is 2

# ls -li a/
total 0
256 drwx------ 1 root root 2 Oct 21 20:41 b

a/b is a subvolume because its inode number is 256

# ls -li a/b
total 0
257 -rw-r--r-- 1 root root 4 Oct 21 20:41 c
# ls -li d/b/
total 0

d/b is an empty directory

> When I snapshot subvolume /sites I can see 
> and navigate through all directories (not subvolumes) below it.  I am 
> assuming that this is expected behavior.  Thanks again for taking the 
> time to help me here.
> Jim
-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: snapshots changed behavior
  2011-10-21 18:43     ` Goffredo Baroncelli
@ 2011-10-21 18:50       ` Jim
  0 siblings, 0 replies; 5+ messages in thread
From: Jim @ 2011-10-21 18:50 UTC (permalink / raw)
  To: Goffredo Baroncelli; +Cc: linux-btrfs

Goffredo,
Here is ls -li of /sites:
[root@btrfs ~]# ls -li /btrfs/test/data
total 0
256 drwx------ 1 root root 8 Oct 21 06:21 sites

It is a subvolume but it contains directories and files below it.  The 
file tree is /btrfs (the mounted btrfs)
/test (a subvolume), /data (a subvolume), /sites (a subvolume) then many 
files and directories below /sites.  Is this information any better?
Jim

On 10/21/2011 02:43 PM, Goffredo Baroncelli wrote:
> On Friday, 21 October, 2011 14:29:11 Jim wrote:
>> Goffredo,
>> Thank you very much for your reply.  That was the information I needed
>> to understand the behavior I was observing.  Just to be sure that I
>> understand correctly, you wrote:
>>
>> I am quite sure that the snapshot is NOT recursive. If a subvolume contains
>> another subvolume, and you snapshot the former, the new subvolume shall not
>> contain the "child" subvolume.
>>
>> when I snapshot /data, a subvolume I can see (but not enter) the
>> subvolume /sites below it.
> You should be able to enter; however in the latter case /sites is a
> subdirectory instead of a subvolume.
>
> To check if a directory is a subvolume, you can see its inode number. If the
> inode number is 256, then the directory is a entry point of a subvolume.
>
>
> See this example
>
>
> # btrfs subvolume create a
> Create subvolume './a'
> # btrfs subvolume create a/b
> Create subvolume 'a/b'
> # echo 123>a/b/c
> # btrfs subvolume snapshot a d
> Create a snapshot of 'a' in './d'
> # ls -li d/
> total 0
> 2 drwxr-xr-x 1 root root 0 Oct 21 20:41 b
>
> d/b is a directory, because its inode number is 2
>
> # ls -li a/
> total 0
> 256 drwx------ 1 root root 2 Oct 21 20:41 b
>
> a/b is a subvolume because its inode number is 256
>
> # ls -li a/b
> total 0
> 257 -rw-r--r-- 1 root root 4 Oct 21 20:41 c
> # ls -li d/b/
> total 0
>
> d/b is an empty directory
>
>> When I snapshot subvolume /sites I can see
>> and navigate through all directories (not subvolumes) below it.  I am
>> assuming that this is expected behavior.  Thanks again for taking the
>> time to help me here.
>> Jim

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-10-21 18:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-21 16:31 snapshots changed behavior Jim
2011-10-21 17:53 ` Goffredo Baroncelli
2011-10-21 18:29   ` Jim
2011-10-21 18:43     ` Goffredo Baroncelli
2011-10-21 18:50       ` Jim

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox