crash when mounting subvolume in a subdirectory
Hi! I'm not sure whether this *should* be possible, but I think it *shouldn't* crash: I created a snapshot of the root directory within a subdirectory: # mount /dev/sde2 /mnt # cd /mnt # mkdir save # btrfs subvolume snapshot . save/snap1 # umount /mnt Then I tried to mount the snapshot: # mount -o subvol=save/snap1 /dev/sde2 /mnt This inevitably leads to a segfault in the btrfs-driver crashing the whole system. I tried this with kernel versions 2.6.32 and 2.6.37.rc4. If I create the subvolume within the root directory of the btrfs volume everything works fine. I'm using btrfs for nearly a year by now (since the release of 2.6.32) and am using subvolumes within subdirectories since then but never tried to directly mount one until today, when my main btrfs volume crashed (by a hardware failure or due to a bug in 2.6.36 - I don't know). If you cannot reproduce this behaviour I can try to send you the kernel log (not so easy, because the system crashes and I will have to write it down by hand). Greetings, Michael -- 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
mount snapshot by object-id
Hi! I'm currently writing a btrfs-rescue tool and therefor began to study the btrfs-on-disk structures in detail. The root tree contains a ROOT_ITEM entry for *every* subvolume in the whole file system, but only DIR_ITEM entries for subvolumes that were created in the root directory of the filesystem. If we have a destroyed root directory, there is no way to access subvolumes stored deeper in the fs-tree by name. It might be nice to have the ability to mount a subvolume by object-id. A simple tool could list all available subvolumes with their object-ids, generation numbers, and so on. Greetings, Michael -- 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
A rescue tool for btrfs
Hi! Last week I crashed a btrfs file system. I didn't lose a lot of data because I had current backups of most data and a full backup from a month ago. But I thought it would be a nice idea to have a rescue tool! Currently I have a first release of this tool (surely buggy and runnning on little endian architectures only). The tool is written in C using the header files from the btrfs userland tools. I use a wrapper (written in a script language) to restore whole directories. Such a wrapper could also detect hard links and handle them correctly. btrfs_rescue implements all disk accesses itself and tries to access only the absolute minimum of necessary data structures to avoid the pitfalls that lurk somewhere in the destroyed file system. So you can rescue parts of a destroyed file system even if the file system driver cannot mount it anymore. The source code is available under http://simplux.org/downloads/btrfs_rescue.c Here is a short overview of the tool's usage: Usage: btrfs_rescue --help shows this short description of available commands btrfs_rescue volumes displays a list of all subvolumes btrfs_rescue dir shows the contents of the root directory btrfs_rescue dir shows the contents of the directory with the specified inode number btrfs_rescue stat displays the status of the file with the specified inode btrfs_rescue cp [--preserve] [--large] creates a copy of the file specified by the inode number under the specified file name The cp-command can copy regular files as well as symbolic links, block and character devices. When copying a directory, only the directory node itself is copied but not its contents! The "--preserve" option preserves access rights, ownership, access time and modification time of the file. The "--large" option allows copying of files larger than 100MB. (A very large file size could stem from the filesystem destruction.) An example output of the above commands: # btrfs_rescue volumes /dev/sde2 5 (generation 227542) 256 (generation 227106) 257 (generation 227553) 258 (generation 227105) 259 (generation 227506) 260 (generation 225276) 261 (generation 224231) ... 314 (generation 226751) 315 (generation 226752) 316 (generation 227104) 317 (generation 227105) 318 (generation 227106) # btrfs_rescue dir /dev/sde2 5 dev: 584 (directory) .backups: 256 (directory) downloads: 259 (directory) boot: 381 (directory) lib: 3504 (directory) sbin: 18685 (directory) save2: 260 (directory) usr: 75153 (directory) opt: 14258 (directory) destination: 1056921 (directory) .joe_state: 1122321 (regular file) data: 583 (directory) bin: 263 (directory) initrd: 257 (directory) save: 259 (directory) home: 258 (directory) net: 14257 (directory) .bash_history: 1325987 (regular file) etc: 585 (directory) source: 1056920 (directory) var: 18959 (directory) tmp: 262 (directory) sys: 261 (directory) mnt: 14256 (directory) proc: 258 (directory) root: 257 (directory) cmds: 408 (directory) # btrfs_rescue dir /dev/sde2 5 584 vbi: 362470 (symbolic link) dri: 1320381 (directory) dmfm2: 361934 (character device) mixer1: 362155 (character device) sequencer: 362269 (character device) hdb4: 361984 (block device) hdc7: 361997 (block device) hda1: 361964 (block device) ... loop0: 362037 (block device) sda9: 362218 (block device) parport0: 362166 (character device) ippp2: 362026 (character device) nvram: 362165 (character device) midi03: 362152 (character device) pts: 362176 (directory) # btrfs_rescue stat /dev/sde2 5 362152 type: 21b0 character device major: 0xe minor: 0x32 size: 0 allocated: 0 links: 1 uid: 17 gid: 0 mode: 0660 access: 2007-07-17 18:58:42.0 +0200 modify: 2007-07-17 18:58:42.0 +0200 change: 2010-05-17 23:33:23.720827790 +0200 Greetings, Michael -- 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: kernel BUG
Hi!
>> Hi! I got a kernel BUG at
>>
>> fs/btrfs/disk-io.c:2311
>>
>> when testing the 2.6.37-rc5 kernel today.
>
> It's good to mention which line this is, since the line numbers are
> always changing. This is:
>
> if (total_errors > max_errors) {
> printk(KERN_ERR "btrfs: %d errors while writing supers\n",
>total_errors);
> BUG();
> }
>
> in write_all_supers(). Does dmesg say anything about the nature of
> the errors above the BUG() line?
The message was output to the console of the crashed system - so I'm sorry I
cannot supply further informations.
But exactly the same crash happened again some minutes ago. (I'm now back to my
old kernel.)
Greetings, Michael
--
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: kernel BUG
Hi, Chris! >> But exactly the same crash happened again some minutes ago. (I'm >> now back to my old kernel.) > > Not sure I understand. Do you mean that the same crash happens on > your older kernel now, or that you've reverted to your older kernel > because you had another -rc5 crash? If the crash happens on -rc5 but > not the older kernel (what revision is the older kernel?), that's > extremely interesting. It happened again on -rc5. But the reason for the crashes could also be a hardware problem - today I used (unintentionally) another USB-port (USB 2.0) for the drive containing the btrfs-file-system then I used (for several month) before (USB 3.0). Currently I'm running with -rc7. If the system still runs tomorrow morning I will do another test with -rc5 - this time on the USB 3.0 port. This should show whether this is a hardware or software problem. Greetings, Michael -- 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: kernel BUG
Hi! It seems that in my case the bug (fs/btrfs/disk-io.c:2311) was caused by a hardware problem. I plugged by accident an usb-3.0-drive (that worked quite well for several weeks) into an usb-2.0-port (which worked quite well for several years). It seems that the two didn't like each other and caused these crashes after some time of idling (it seems that the idling is necessary for the crash, cause it never crashed while I was actually working). Greetings, Michael -- 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
/dev/btrfs-control
Some btrfs-tools make use of "/dev/btrfs-control". How should I create this node? Is this a block or a character device (I suppose it should be a character device), which major and minor numbers should be assigned? I do not use udev, so I have to create all device nodes "by hand" or "by script". I started using btrfs with the arrival of kernel 2.6.32 - no problems until now! :-) I'm very interested in using its snapshot feature. Currently I'm not able to mount a snapshot (subvolume), but this might be connected to the missing device-node. Thanks in advance for any help, Michael -- 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
snapshots of directories
I try to take a snapshot of a single directory, e.g. root: > btrfsctl -s root.2010-01-12 /root operation complete Btrfs v0.19-4-gab8fb4c-dirty Then I take look what's inside the newly created snapshot: > ls -l /root.2010-01-12/ total 0 drwxr-xr-x 1 root root 1192 2010-01-03 20:32:12 bin drwxr-xr-x 1 root root 76 2009-06-25 0:40:35 boot drwxr-xr-x 1 root root 1756 2010-01-12 2:33:07 cmds drwxr-xr-x 1 root root0 2010-01-06 12:21:46 data drwxr-xr-x 1 root root 4356 2010-01-12 2:07:00 dev drwxr-xr-x 1 root root 42 2010-01-04 12:29:45 downloads drwxr-xr-x 1 root root 4528 2010-01-12 2:12:12 etc drwxr-xr-x 1 root root 52 2010-01-11 12:57:47 home drwxr-xr-x 1 root root0 2007-11-10 4:44:07 initrd drwxr-xr-x 1 root root 4490 2010-01-05 20:15:53 lib drwxr-xr-x 1 root root 124 2008-04-27 14:53:39 mnt drwxr-xr-x 1 root root 62 2008-01-08 0:21:58 net drwxr-xr-x 1 root root0 2008-04-09 3:19:16 objects drwxr-xr-x 1 root root 316 2009-12-28 23:23:13 opt dr-xr-xr-x 1 root root0 2007-11-10 3:35:28 proc drwxr-xr-x 1 root root 7676 2010-01-11 0:35:41 root drwxr-xr-x 1 root root0 2010-01-12 1:56:17 save drwxr-xr-x 1 root root0 2010-01-12 1:55:58 save2 drwxr-xr-x 1 root root 3804 2010-01-06 2:36:08 sbin drwxr-xr-x 1 root root0 2007-11-10 3:35:28 sys drwxr-xr-x 1 root root 358 2010-01-11 18:44:29 tmp drwxr-xr-x 1 root root 176 2009-12-29 17:08:37 usr drwxr-xr-x 1 root root 72 2010-01-05 20:03:00 var It seems that always a snapshot of the root is taken instead one of the specified directory? Is this by design? Snapshotting the root works fine, but if you take several snapshots it's a bit "recursive", because every new snapshot contains all previous snapshots. Greetings, Michael -- 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
Free space left
How can I detect how much free space is left on a btrfs-volume? As I read (and learned in practice!) "df" reports cannot be trusted if used on btrfs-volumes. Greetings, Michael -- 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: [RFC] Move all btrfs command to only one command
> $ btrfs > Usage: > btrfs clone|-c [/] > Clone the subvolume with the name in the > > directory. > > btrfs delete|-d > Delete the subvolume . > btrfs create|-C [/] > Create a subvolume in (or the current directory if not > passed. > btrfs defrag|-d | [|...] > Defragment a file or a directory. > btrfs fssync|-s > Force a fs sync on the filesystem > btrfs resize|-r [+/-][gkm]|max > Resize the file system. If 'max' is passed, the filesystem > will occupe all available space on the device. > btrfs scan|-S [ [..] > Scan all device for or the passed device for a btrfs > filesystem. > btrfs show|-l | [|.. ] > Show the btrfs devices > btrfs balance|-b > Balance teh chunk across the device > btrfs add|-A > Add a device to a filesystem > btrfs rem|-R > Remove a device to a filesystem > > btrfs help|--help|-h > Show the help. I like this idea! Just a small suggestion: "btrfs remove" instead of "btrfs rem" - Another question: Is there a simple way to convert a directory into a subvolume? Currently I first create the new subvolume; copy or move the data of the directory into the new subvolume, then delete the directory and finally rename the subvolume. Greetings, Michael -- 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
btrfsck failed
I tried an (offline) btrfsck and got the following error message: > btrfsck /dev/sdb3 btrfsck: btrfsck.c:584: splice_shared_node: Assertion `!(src == &src_node->root_cache)' failed. Aborted I use kernel version 2.6.32.2 with builtin btrfs-drivers. Greetings, Michael -- 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
severe hardlink bug
I'm using btrfs with a kernel 2.6.32.2 (builtin) as the root file system of a Gentoo Linux installation. While attempting to install the plt-scheme package a strange error about link counts occurred ([Error 31] Too many Links). I was able to create a simple scenario to reproduce the error: Create an empty directory and run the following script within the directory: #!/bin/bash echo "abc" >.tab-snip-class_scrbl.dep._portage_merge_.9766 for x in $(seq 80) do echo $x; ln .tab-snip-class_scrbl.dep._portage_merge_.9766 \ .tab-snip-class_scrbl.dep._portage_merge_.9766.$x; done (The names are taken from the original Gentoo package.) When I run this script the first 66 links are created properly. All further link creations fail: ... 63 64 65 66 67 ln: creating hard link to `.tab-snip-class_scrbl.dep._portage_merge_.9766': Too many links 68 ln: creating hard link to `.tab-snip-class_scrbl.dep._portage_merge_.9766': Too many links 69 ln: creating hard link to `.tab-snip-class_scrbl.dep._portage_merge_.9766': Too many links 70 ln: creating hard link to `.tab-snip-class_scrbl.dep._portage_merge_.9766': Too many links ... I was able to reproduce the bug independently on two different machines. During earlier tests I determined that filename length has an effect as well as the link count. Greetings, Michael -- 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 subvol find-new
I want to write a differential backup tool for btrfs snapshots. The new "btrfs subvol find-new"-command sounds great on first encounter, but I'm missing informations about updated directories. I would need a list of updated directories to scan for deleted files. I had a look at find_updated_files() in btrfs-list.c. To me it seems as if the ioctl would only return the extents of regular files. The function find_root_gen() in btrfs-list.c seems to return the newest generation in a given snapshot. It would be nice to have this exported as a user command (e.g. "btrfs subvol newest-gen") then one could use the output of btrfs subvol newest-gen (plus 1) as the input generation number to btrfs subvol find-new (I'm using kernel 2.6.32.10 with the most current btrfs-kernel modules and userland tools as of last Saturday.) Greetings, Michael -- 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: Number of hard links limit
> Also, I believe it's not strictly 256 links, it's dependent on the length > of the names. > > I recall Chris posting something about being able to fix this without a > format change, though it wasn't a priority yet. As to my knowledge the limit is 64KB for all names of a single file and due to Chris it will take a format change to fix this. I ran into the limit some month ago while installing some Gentoo packages. Greetings, Michael -- 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-images
Hi! I also wanted to use btrfs-images, but changed my mind when I got troubles with several btrfs file systems derived from the same image. If more than one of these file system were physically connected at the same time, mounting one of them resulted in a mess. I think they all used the same internal ids and btrfs thought them to be one single file system stretched over several media. So I decided to create a fresh btrfs file system every time and copy the files from an archive (which is much slower). Is there a workaround? Greetings, Michael -- 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: mount snapshot by object-id
Hi, Calvin! Thanks a lot for this information and for updating the wiki! The option works - on healthy disks ... I will continue writing my rescue-tool. I also wrote a btrfs_subvolumes command that displays all subvolumes of an unmounted filesystem. This helps a lot if mounting the filesystem leads to a crash! Greetings, Michael -- 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
kernel BUG
Hi! I got a kernel BUG at fs/btrfs/disk-io.c:2311 when testing the 2.6.37-rc5 kernel today. The system crashed while doing really nothing for a few minutes. Greetings, Michael -- 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
Still Problems with /dev/btrfs-control
Thanks for the quick reply! But I still have problems with btrfsctl: > stat /dev/btrfs-control File: `/dev/btrfs-control' Size: 0 Blocks: 0 IO Block: 4096 block special file Device: ch/12d Inode: 659848 Links: 1 Device type: a,3e Access: (0644/brw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2010-01-09 11:31:15.757979602 +0100 Modify: 2010-01-09 11:31:15.757979602 +0100 Change: 2010-01-09 11:31:15.757979602 +0100 > mount -l -t btrfs /dev/sda3 on / type btrfs (rw,relatime,noacl) [Alpha4] > btrfsctl -A /dev/sda3 failed to open /dev/btrfs-control: No such device or address Remark: When the btrfs-filesystem is originally mounted (from the startup-code in the initial ramdisk), /dev/btrfs-control is not yet existant, because the dev-directory is contained in the btrfs-filesystem. Everything else works fine. Greetings, Michael -- 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
How to mount a subvolume?
First thanks alot to Kay and Goffredo! But I have another question. I read that the current tools cannot display subvolumes, but one should still be able to mount them. If I try I get an error message: > mount -t btrfs -o subvol=root.2010-01-07 /dev/sda3 /save mount: /dev/sda3 is not a valid block device root.2010-01-07 is a snapshot of the /root-directory /save is an empty directory used for mounting backups taken (successfully) with the following command: > btrfsctl -s root.2010-01-07 /root What am I doing wrong? Isn't it possible to mount the whole filesystem and a subvolume at the same time? Greetings, Michael -- 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: How to mount a subvolume?
Hi, Dirk! > Does /dev/sda3 actually exist? /dev/sda3 does exist; it is an btrfs formatted partition containing my root file system: > mount ... /dev/sda3 on / type btrfs (rw,relatime,noacl) ... Greetings, Michael @Johannes: I will recreate the /dev/brtfs-control device node in the startup scripts using the information from /sys/class/misc/btrfs-control/dev - 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
btrfsctl -s returns 1
I wrote a script generating snapshots of several subvolumes. But the script failed after taking the first snapshot. I then did it by hand: > btrfsctl -s /.backups/2010-01-12.1/home /home operation complete Btrfs v0.19-4-gab8fb4c > echo $? 1 Usually commands return 0 if everything went ok (and it seems that the snapshot was taken correctly). Has the returned "1" some special meaning? -- Another, minor issue: Mayby my manual is out of date. It tells me > man btrfsctl ... -s snapshot-name directory Creates a new snapshot of the directory specified. ... but as I learned one can only take a snapshot of a subvolume. Greetings, Michael -- 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: Free space left
Hi, Goffredo! > Try btrfs-show Thanks for your advice! btrfs-show works but it displays a lot of error message for non-btrfs devices: > btrfs-show failed to read /dev/sdg failed to read /dev/sdg1 failed to read /dev/sdg2 failed to read /dev/sdg3 failed to read /dev/sdg4 failed to read /dev/md1 failed to read /dev/fd0 failed to read /dev/fd0u1440 failed to read /dev/fd1 failed to read /dev/hda failed to read /dev/hda1 failed to read /dev/hda10 failed to read /dev/hda11 failed to read /dev/hda12 ... failed to read /dev/sr0 failed to read /dev/sr1 failed to read /dev/sr2 failed to read /dev/sr3 ... Label: Alpha4 uuid: 63b82dad-ed81-41f4-910f-7b358ceb77ba Total devices 1 FS bytes used 11.81GB devid1 size 20.01GB used 20.01GB path /dev/sda3 Btrfs v0.19-4-gab8fb4c Even if I try btrfs-show /dev/sda3 I get the same output. Greetings, Michael -- 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: severe hardlink bug
Hi, Goffredo! > See this thread: > Mass-Hardlinking Oops - http://thread.gmane.org/gmane.comp.file- > systems.btrfs/3427 Sorry, I didn't find the thread myself - despite of massive googeling. :-( The gentoo scenario however is a real world application - no artificial situation, so it would be really nice to fix the hard link problem somewhere in the future! The problem will happen in all busybox-like scenarios - and long filenames are not so rarely used. Greetings, Michael -- 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: severe hardlink bug
Hi, Goffredo! I understood that a disk layout change will be necessary to accomodate for a bigger total filename-space per file. So it is best done at once when more issues arise that will need layout changes. To recreate the error situation you need a Gentoo Linux with a btrfs root file system and then try to install the plt-scheme package: > emerge plt-scheme Compilation works quite fine, but the installation aborts with a "Too many links" error. I reinstalled over 700 packages - plt-scheme beeing the only one failing due to the btrfs link restriction. Greetings, Michael -- 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: What's the benefit of COW without checksum?
I'm using btrfs for a distribution specialized to be used with USB pen drives. btrfs ist the first file system (besides nilfs) that is fast enough to be used with media (flash memory) that has a severe restriction on the number of writes per second (to be more precise: the number of page deletes per second). Until now I had to use a layered approached using some kind of union file system and a ramdisk as the top level layer. I first testet btrfs last June when it entered the official kernel. At that time is was much to slow to be used in the described scenario. But the speedups during the last months made its use possible! :-) So lots of thanks to Chris Mason and all others who brought us such a groundbreaking file system. They have done a great piece of work. Yet there's still a lot to be done, but I'm optimistic that we will end up with a very well designed file system useable for lots of different application scenarios. Greetings, Michael -- 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 0/2] btrfs: a new tool to manage a btrfs filesystem
When creating new commands I always prefer increased readability and meaningfull names for subcommands and options. If one often enters commands directly at the command prompt one could use shell-aliases, if written in scripts long names make the scripts much easier to understand. It's great that we now have one single tool! Lot of thanks to Goffredo! Greatings, Michael -- 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 subvol find-modified
I have added a command btrfs subvolume find-modified List the recently modified files and directories in a filesystem. It's similar to find-new with the following differences: * in addition to modified files it will also display modified directories * it lists only the paths of the modified files and directories (no extent information) Directories "." and ".." are filtered. I will do extensive testing this weekend and then post the patch to this list if wanted - if I'm able to master git until then ... ^^ Greetings, Michael -- 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 subvol find-modified
Hi, Chris! > Add an optional timestamp field to filter > files that have changed since a given timestamp. Is there a possibility to derive the timestamp directly from the generation number? If we have a "-e"-switch for printing extent-information we could also have another switch to decide whether to print directory-information or not and combine find-new and find-modified into a single command. Meanwhile I have implemented the (very simple) command btrfs subvolume max-gen Print the highest generation number in a filesystem. Greetings, Michael -- 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 subvol diff
> It is possible to combine the commands max-gen and find-new ? Something like: > > $ btrfs subvol find-new subvol1 snap1 I had very similar thoughts myself. If we compare two snapshots (of the same subvolume) we wouldn't need timestamps either, e.g.: btrfs subvol diff The output could be a list of files (and directories); each line prefixed with a plus sign (for new or modified files) or a minus sign (for deleted files). The output could be easily postprocessed using grep and cut. Greetings, Michael -- 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
directory order in btrfs
Hi, Chris! I'm writing the btrfs snapshot diff tool and I would like to know, whether the entries in a btrfs directory are ordered in some way. I want to find missing entries in a new snapshot's directory. Can I do a "linear compare" of the old and new directories or do I have to sort the entries first (or do some kind of hashing)? Greetings, Michael -- 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
Missing entry for updated directory
I'm using BTRFS_DIR_INDEX_KEY as suggested by Chris to find all updated directories. But I'm missing one: The directory has 3 entries deleted and stat shows different mtimes and ctimes for the directory in the two snapshots. The highest generation number in the older snapshot is 82623. But the generation number of the updated directory is 31758 in both snapshots. Greetings, Michael -- 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: Missing entry for updated directory
Hi, Goffredo! I checked all btrfs-item types (changed sk->max_type to 255 and removed the filtering) connected with the updated directory's inode. But none of them had got a new generation number. I found the missing directory only using a more conventional tool that checked all files and directories in both snapshots. Here the output from stat: >stat 2010-03-21/root/.googleearth/Temp/.kmztmp/ File: `2010-03-21/root/.googleearth/Temp/.kmztmp/' Size: 21340 Blocks: 0 IO Block: 4096 directory Device: 15h/21d Inode: 31757 Links: 1 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-02-19 22:12:25.339932662 +0100 Modify: 2009-11-18 13:45:52.0 +0100 Change: 2010-01-12 19:48:01.911913031 +0100 >stat 2010-03-22/root/.googleearth/Temp/.kmztmp/ File: `2010-03-22/root/.googleearth/Temp/.kmztmp/' Size: 21268 Blocks: 0 IO Block: 4096 directory Device: 16h/22d Inode: 31757 Links: 1 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-02-19 22:12:25.339932662 +0100 Modify: 2010-03-21 21:49:16.512553912 +0100 Change: 2010-03-21 21:49:16.512553912 +0100 Greetings, Michael -- 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
