Re: btrfs hang (deadlock?) when trying to create a ext4 filesystem in KVM guest
On Thu, Oct 28, 2010 at 1:29 AM, Tomasz Chmielewski man...@wpkg.org wrote: On 28.10.2010 00:55, Chris Mason wrote: On Wed, Oct 27, 2010 at 03:29:38PM +0200, Tomasz Chmielewski wrote: There are a couple of problems when running KVM guests with images stored on btrfs filesystem. One of them is inability to create a filesystem (i.e. ext4) in the guest: - btrfs filesystem on the host was mounted with noatime,compress-force - guest was using a 50 GB sparse file, - attempt to create a ext4 filesystem within the guest does not succeed (hangs); host prints below messages in dmesg - some deadlock in btrfs? kernel: 2.6.36 qemu-kvm: 0.13.0 Is this the full dmesg output? I think there are other messages hiding in there. There were indeed bad ordered accounting left (see below), I think they are coming from btrfs? Is this a single disk btrfs? Yes. [ 8072.773053] device fsid 1142843480ad2d13-4bdc742fd9b1f7b0 devid 1 transid 1508 /dev/sdb4 [ 8072.773674] btrfs: forcing compression [ 8122.052221] device tap0 entered promiscuous mode [ 8122.052245] br0: port 2(tap0) entering learning state [ 8122.052248] br0: port 2(tap0) entering learning state [ 8122.451587] br0: port 2(tap0) entering learning state [ 8122.543477] br0: port 2(tap0) entering disabled state [ 8122.609645] device tap0 left promiscuous mode [ 8122.609650] br0: port 2(tap0) entering disabled state [ 8131.325647] EXT4-fs (md4): recovery complete [ 8131.325809] EXT4-fs (md4): mounted filesystem with ordered data mode. Opts: (null) [ 8133.392100] device tap0 entered promiscuous mode [ 8133.392127] br0: port 2(tap0) entering learning state [ 8133.392131] br0: port 2(tap0) entering learning state [ 8134.106594] kvm: 5004: cpu0 unhandled wrmsr: 0x198 data 0 [ 8134.106618] kvm: 5004: cpu1 unhandled wrmsr: 0x198 data 0 [ 8143.460927] tap0: no IPv6 routers present [ 8148.359485] br0: port 2(tap0) entering forwarding state [ 8309.103502] bad ordered accounting left 65536 size 385024 [ 8309.106206] bad ordered accounting left 65536 size 385024 [ 8309.108915] bad ordered accounting left 65536 size 385024 [ 8309.111630] bad ordered accounting left 36864 size 385024 [ 8501.965625] INFO: task qemu-system-x86:5148 blocked for more than 120 seconds. [ 8501.965629] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 8501.965632] qemu-system-x D 880001e14cc0 0 5148 4924 0x [ 8501.965638] 880223bc3b38 0086 880223bc3fd8 00014cc0 [ 8501.965642] 00014cc0 880223bc3fd8 00014cc0 880223bc3fd8 [ 8501.965647] 00014cc0 880221965f18 880221965f20 880221965b80 [ 8501.965651] Call Trace: [ 8501.965678] [a024c52c] btrfs_start_ordered_extent+0x6c/0xb0 [btrfs] [ 8501.965685] [81083200] ? autoremove_wake_function+0x0/0x40 [ 8501.965701] [a024d1c2] btrfs_wait_ordered_range+0xd2/0x160 [btrfs] [ 8501.965716] [a0240059] btrfs_file_aio_write+0x269/0x990 [btrfs] [ 8501.965721] [8105ca94] ? try_to_wake_up+0xf4/0x3f0 [ 8501.965726] [81168119] ? __pollwake+0x49/0x50 [ 8501.965730] [8105cd90] ? default_wake_function+0x0/0x20 [ 8501.965733] [8105ca94] ? try_to_wake_up+0xf4/0x3f0 [ 8501.965737] [8116813b] ? pollwake+0x1b/0x20 [ 8501.965752] [a023fdf0] ? btrfs_file_aio_write+0x0/0x990 [btrfs] [ 8501.965761] [8115664b] do_sync_readv_writev+0xcb/0x110 [ 8501.965769] [81294d98] ? apparmor_file_permission+0x18/0x20 [ 8501.965776] [8126356e] ? security_file_permission+0x1e/0x80 [ 8501.965781] [811576e0] do_readv_writev+0xd0/0x1d0 [ 8501.965787] [81076d72] ? kill_something_info+0x42/0x130 [ 8501.965793] [81076ee0] ? sys_kill+0x80/0x90 [ 8501.965798] [8115781e] vfs_writev+0x3e/0x60 [ 8501.965802] [811578e7] sys_pwritev+0xa7/0xc0 [ 8501.965806] [8100b0f2] system_call_fastpath+0x16/0x1b [ 8501.965810] INFO: task qemu-system-x86:5150 blocked for more than 120 seconds. [ 8501.965812] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 8501.965814] qemu-system-x D 880001e94cc0 0 5150 4924 0x [ 8501.965819] 8801aba4bb38 0086 8801aba4bfd8 00014cc0 [ 8501.965823] 00014cc0 8801aba4bfd8 00014cc0 8801aba4bfd8 [ 8501.965827] 00014cc0 880226d14838 880226d14840 880226d144a0 [ 8501.965832] Call Trace: [ 8501.965847] [a024c52c] btrfs_start_ordered_extent+0x6c/0xb0 [btrfs] [ 8501.965852] [81083200] ? autoremove_wake_function+0x0/0x40 [ 8501.965867] [a024d1c2] btrfs_wait_ordered_range+0xd2/0x160 [btrfs] [ 8501.965883] [a0240059] btrfs_file_aio_write+0x269/0x990 [btrfs] [ 8501.965887] [8105ca94] ? try_to_wake_up+0xf4/0x3f0 [ 8501.965891] [81168119] ?
Scary OOPS when playing with --bind, --move, and friends
hello, i really need to stop recklessly doing this stuff to my laptop... i'm finishing a new initramfs hook to support many features of btrfs; when considering how i was going to mount the target subvol as / for the booting system, i decided to play with --bind and --move. in short, everything works fine until you --bind across a subvol via the special folders created when one takes a snapshot, or --bind the special folder itself. the --bind succeeds, and everything initially appears to work fine... this is nearly the exact process i did; should reproduce :-(i'm scared to do it again...): - # mkdir -p sand/root sand/bind # cd sand # mount -o subvolid=0 /dev/sda root # mount --bind root/subvol of my current root/home/anthony bind # touch bind/TEST you can now see TEST at ~/TEST and bind/TEST # vim bind/TEST did it work? :wq you can see the edited version ONLY in the one you edited... the other is still 0 bytes # vim ~/anthony/TEST 1 wtf, why not? :wq machine panics, X is instantly replaced by an oopsie screen; machine locked - i don't know why i decided to stupidly edit the bad version, even though something was clearly wrong. at any rate, this was about 15 minutes ago... the machine booted back up alright after a hard reboot, hooray for that, but methinks there is probably some corruptions in there now... meh. i don't know what it means, but when the two versions desynced (it could have been like this, but i didn't notice until after the desync), `ls -l` reported a `0` right after the permissions: -rw-r--r-- 0 anthony users 8 Dec 20 21:41 TEST all other files report `1`. since /dev and /proc etc. have different numbers, this appears to have something to do with the mount or device? i panicked wen the kernel did, and i forgot to write down the message, but the trace had `vfs_rename` and `tomoyo_???`... sorry for the bad memory. vim was attempting to move a temporary file over the top of the misbehaving file, hence the rename. i'm on 2.6.36.2 the `directory as a subvol` thing seems to be a little finicky :-) did i do something incorrect? should this kind of operation be supported? it seems to work fine so long as i stay on the same subvol. thanks, 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: Scary OOPS when playing with --bind, --move, and friends
On Mon, Dec 20, 2010 at 10:19 PM, Fajar A. Nugraha l...@fajar.net wrote: On Tue, Dec 21, 2010 at 11:16 AM, Fajar A. Nugraha l...@fajar.net wrote: On Tue, Dec 21, 2010 at 10:51 AM, C Anthony Risinger anth...@extof.me wrote: i'm on 2.6.36.2 Try 2.6.35 or later. I tested something similar under ubuntu maverick (2.6.35-24-generic) and it works just fine. Sorry, hit send to soon. I though you wrote 2.6.32 :P Still curious about your test scenario though. Can you double check it? A write on the snapshot should not appear on the parent filesystem. sorry maybe i wasn't very clear; my current root is a subvol... the directory i was --bind mounting corresponded to /home/anthony: / and root/subvol of my current root are the same; so it should show up in my /home/anthony directory. if mount the subvol by id, then --bind mount, it works as expected; only when crossing the magic barrier doesn't things seem to freak out. i actually reproduced it twice, but this time i didn't write to the files :-) 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: Scary OOPS when playing with --bind, --move, and friends
On Mon, Dec 20, 2010 at 10:25 PM, C Anthony Risinger anth...@extof.me wrote: On Mon, Dec 20, 2010 at 10:19 PM, Fajar A. Nugraha l...@fajar.net wrote: Still curious about your test scenario though. Can you double check it? A write on the snapshot should not appear on the parent filesystem. sorry maybe i wasn't very clear; my current root is a subvol... the directory i was --bind mounting corresponded to /home/anthony: / and root/subvol of my current root are the same; so it should show up in my /home/anthony directory. if mount the subvol by id, then --bind mount, it works as expected; only when crossing the magic barrier doesn't things seem to freak out. s/doesn't/do/g to be exact, it looks like this: - (subvolid) source mount [options] (262) /dev/sda / (__0) /dev/sda /home/anthony/sand/root [subvolid=0] (???) /home/anthony/sand/root/vols/262/home/anthony /home/anthony/sand/bind [--bind] - all my subvolumes are kept in a vols directory in the btrfs root, so my / and the --bind mount were suppose to be referencing the same location. additionally, TEST showed up in both locations... it was the editing part that blew up. NOTE however, that the subvol (id 262) itself was _never_ actually mounted, it was accessed thru the btrfs root mounted at `root`. i think this is the crux of the problem; --bind doesn't seem to know that the directory it was binding isn't 100% within the mount point it resides under. 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: [GIT PULL][PATCH v2 0/6] btrfs: Add lzo compression support
On Dec 24, 2010, at 2:46 PM, Chris Mason chris.ma...@oracle.com wrote: This is going to be the building block for our 2.6.38 pull request to Linus. hooray christmas came early this year! what a nice gift, thanks! heh, thanks for all the great work guys. I'm doing my best to spread the good btrfs word all over the net, correcting misconceptions, writing guides/hooks/scripts, and generally helping those that need it; the majority are most impressed, and looking forward to the onset. Just thought I'd say that my travels have found many satisfied users, who are, including myself, very appreciative of the work being done here. So thanks! Happy holidays! And to all a good night! C Anthony [mobile] -- 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: Synching a Backup Server
On Thu, Jan 6, 2011 at 1:47 PM, Freddie Cash fjwc...@gmail.com wrote: On Thu, Jan 6, 2011 at 11:33 AM, Marcin Kuk marcin@gmail.com wrote: Rsync is good, but not for all cases. Be aware of databases files - you should do snapshot filesystem before rsyncing. We script a dump of all databases before the rsync runs, so we get both text and binary backups. If restoring the binary files doesn't work, then we just suck in the text dumps. If the remote system supports snapshots, doing a snapshot before the rsync runs is a good idea, though. It'll be nice when more filesystems support in-line snapshots. The LVM method is pure crap. do you also use the --in-place option for rsync? i would think this is critical to getting the most out of btrfs folding backups, ie. the most reuse between snapshots? im able to set this exact method up for my home network, thats why i ask... i have a central server that runs everything, and i want to sync a couple laptops and netbooks nightly, and a few specific directories whenever they change. btrfs on both ends. better yet, any chance you'd share some scripts? :-) as for the DB stuff, you definitely need to snapshot _before_ rsync. roughly: ) read lock and flush tables ) snapshot ) unlock tables ) mount snapshot ) rsync from snapshot ie. the same as whats needed for LVM: http://blog.dbadojo.com/2007/09/mysql-backups-using-lvm-snapshots.html to get the DB file on disk consistent prior to archiving. 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: Synching a Backup Server
On Thu, Jan 6, 2011 at 2:13 PM, Freddie Cash fjwc...@gmail.com wrote:
On Thu, Jan 6, 2011 at 12:07 PM, C Anthony Risinger anth...@extof.me wrote:
On Thu, Jan 6, 2011 at 1:47 PM, Freddie Cash fjwc...@gmail.com wrote:
On Thu, Jan 6, 2011 at 11:33 AM, Marcin Kuk marcin@gmail.com wrote:
Rsync is good, but not for all cases. Be aware of databases files -
you should do snapshot filesystem before rsyncing.
We script a dump of all databases before the rsync runs, so we get
both text and binary backups. If restoring the binary files doesn't
work, then we just suck in the text dumps.
If the remote system supports snapshots, doing a snapshot before the
rsync runs is a good idea, though. It'll be nice when more
filesystems support in-line snapshots. The LVM method is pure crap.
do you also use the --in-place option for rsync? i would think this
is critical to getting the most out of btrfs folding backups, ie.
the most reuse between snapshots? im able to set this exact method up
for my home network, thats why i ask... i have a central server that
runs everything, and i want to sync a couple laptops and netbooks
nightly, and a few specific directories whenever they change. btrfs
on both ends.
Yes, we do use --inplace, forgot about that one.
Full rsync command used:
${rsync} ${rsync_options} \
--exclude-from=${defaultsdir}/${rsync_exclude} ${rsync_exclude_server} \
--rsync-path=${rsync_path} --rsh=${ssh} -p ${rsync_port} -i
${defaultsdir}/${rsync_key} \
--log-file=${logdir}/${rsync_server}.log \
${rsync_us...@${rsync_server}:${basedir}/
${backupdir}/${sitedir}/${serverdir}/${basedir}/
Where rsync_options is:
--archive --delete-during --delete-excluded --hard-links --inplace
--numeric-ids --stats
better yet, any chance you'd share some scripts? :-)
A description of what we use, including all scripts, is here:
http://forums.freebsd.org/showthread.php?t=11971
ah nice, i was hoping i didn't have to write it all myself; thanks!
as for the DB stuff, you definitely need to snapshot _before_ rsync.
roughly:
) read lock and flush tables
) snapshot
) unlock tables
) mount snapshot
) rsync from snapshot
Unfortunately, we don't use btrfs or LVM on remote servers, so there's
no snapshotting available during the backup run. In a perfect world,
btrfs would be production-ready, ZFS would be available on Linux, and
we'd no longer need the abomination called LVM. :)
heh, ain't 'dat the truth.
Until then, DB text dumps are our fall-back. :)
always good to have that contingency plan :-)
thanks again,
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: Various Questions
On Fri, Jan 7, 2011 at 11:15 AM, Carl Cook cac...@quantum-sci.com wrote: On Fri 07 January 2011 08:14:17 Hubert Kario wrote: I'd suggest at least mkfs.btrfs -m raid1 -d raid0 /dev/sdc /dev/sdd if you really want raid0 I don't fully understand -m or -d. Why would this make a truer raid0 that with no options? this will give you RAID0 for your data, but RAID1 for your metadata, making it less likely that the FS itself gets corrupted, even though you will lose some data in crash cases, if i understand correctly. Is it necessary to use fdisk on new drives in creating a BTRFS multi-drive array? Or is this all that's needed: # mkfs.btrfs /dev/sdb /dev/sdc # btrfs filesystem show depends on whether you need /boot partitions or other partitions. what you have works fine though. Is this related to 'subvolumes'? The FAQ implies that a subvolume is like a directory, but also like a partition. What's the rationale for being able to create a subvolume under a subvolume, as Hubert says so he can use the shadow_copy module for samba to publish the snapshots to windows clients. I don't have any windows clients, but what difference does his structure make? just his preference to put it there... the snapshot of a snapshot can go anywhere. it doesn't have to reside under it's parent, the parent was just used as a base, it's not bound to it in any way AFAIK. How do you know what options to rsync are on by default? I can't find this anywhere. For example, it seems to me that --perms -ogE --hard-links and --delete-excluded should be on by default, for a true sync? the links and command Freddie Cash posted are a really good base to work from. So for my system where there is a backup server, I guess I run the rsync daemon on the backup server which presents a port, then when the other systems decide it's time for a backup (cron) they: - stop mysql, dump the database somewhere, start mysql; - connect to the backup server's rsync port and dump their data to (hopefully) some specific place there. Right? you don't have to stop mysql, you just need to freeze any new, incoming writes, and flush (ie. let finish) whatever is happening right now. this ensures mysql is _internally_ consistent on the disk. see comment by Lloyd Standish here: http://dev.mysql.com/doc/refman/5.1/en/backup-methods.html 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: no space left on device
On Mon, Feb 7, 2011 at 3:21 PM, Leonidas Spyropoulos artafi...@gmail.com wrote: Hey all, I run into no space left on device on a virtualbox After installing Debian 6 on a virtual machine I tried installing the KDE desktop The system HDD is 8Gb Both root (/) and /home are btrfs over LVM. While installing the packages I run into: no space left, need 4096, 4096 dealloc bytes, 1776283648 bytes_used, 0 bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0 may use 1776287744 total df shows only 74% used space on / kernel used: stock debian 6 2.6.32-5-686 At the moment I cannot access it with normal boot, only recovery mode. I can provide whatever info you would like as long as you think of a way to load the normal system and not the recovery mode. IIRC .32 has all sorts of ENOSPC problems; I think this was seriously tackled in kernels .32... this kernel was only declared ready for early adopters, with an expect issues disclaimer. The btrfs-tools in squeeze is probably so old you may not even have the `btrfs` binary, but I don't run debian so I'm not sure there... not really a solution probably for you, but I wouldn't run that kernel if using btrfs. 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: Cannot Deinstall a Debian Package
On May 6, 2011 4:20 PM, cac...@quantum-sci.com wrote: On Friday 6 May, 2011 13:51:37 Peter Stuge wrote: cac...@quantum-sci.com wrote: I don't understand this. Clearly. Please continue the discussion in a debian or grub forum.. It really has nothing to do with btrfs. No thanks. This is a BTRFS problem, and if you people don't want to face it, that's fine. I'm tearing out BTRFS and using another filesystem. And rest assured, I'm warning others too. That's enough. hm. well to anyone who stumbles across this thread in the future, i've managed to use btrfs as my root on 1-3+ machines since circa 2.6.32, possibly even earlier (albeit not on Debian -- Archlinux w00tw00t ;-) ... ... there have certainly been a few bumps along the way, but not _once_ at the fault of btrfs ... not ONCE. tbh, I personally KNOW the developers and community here are doing one hell of a job -- i've been on this list almost 3 years i think, and along the way everyone has been most helpful + accommodating; i mean i've seen Chris and others extending rather gracious support levels when helping users recover data or debug issues ... and considering the demand/anticipation surrounding btrfs, this list is relatively devoid of support issues -- it's easily one of the highest quality groups i frequent. in short, distro's only just recently began offering btrfs at install time, with a big *warning sticker* on it. as others have already stated, this is clearly a Debian-specific problem, and does not reflect negatively on btrfs whatsoever, which has been nothing short of spectacular since the day i tried it and very much exactly as advertised -- i haven't used anything else since (save my servers ...). i am sorry you've found yourself in this position, i really am, as i've been there myself, but please do try and acknowledge the considerations already extended your way -- my post marks the 51st message in this thread. 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: Cannot Deinstall a Debian Package
On Fri, May 6, 2011 at 8:51 PM, C Anthony Risinger anth...@extof.me wrote: On May 6, 2011 4:20 PM, cac...@quantum-sci.com wrote: On Friday 6 May, 2011 13:51:37 Peter Stuge wrote: cac...@quantum-sci.com wrote: I don't understand this. Clearly. Please continue the discussion in a debian or grub forum.. It really has nothing to do with btrfs. No thanks. This is a BTRFS problem, and if you people don't want to face it, that's fine. I'm tearing out BTRFS and using another filesystem. And rest assured, I'm warning others too. That's enough. i am sorry you've found yourself in this position, i really am, as i've been there myself, but please do try and acknowledge the considerations already extended your way -- my post marks the 51st message in this thread. i see now that you're running a .32 kernel ... a bit after the fact, but i really wouldn't recommend using anything that old for something that's in such active development; IIRC, there were many feature gaps at that point (ENOSPC being the big one), and unless Debian is doing something special, .32 was when btrfs was declared ready for early adopters ... ie. stable was still way out on the horizon, no one even knew what she might look like yet :-) 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: [PATCH] Btrfs: make lzo the default compression scheme
On Fri, May 27, 2011 at 2:41 AM, Fajar A. Nugraha l...@fajar.net wrote: On Fri, May 27, 2011 at 2:32 PM, Sander san...@humilis.net wrote: Li Zefan wrote (ao): As the lzo compression feature has been established for quite a while, we are now ready to replace zlib with lzo as the default compression scheme. Please be aware that grub2 currently can't load files from a btrfs with lzo compression (on debian sid/experimental at least). Just found out the hard way after a kernel upgrade on a system with no separate /boot partition :-) Found this: https://bugs.archlinux.org/task/23901 IIRC what matters is compression actually used by the files. If /boot/grub/* and kernel/initrd is not compressed, or compressed with zlib, then grub2 can read it just fine, even when the filesystem is usually mounted with -o compress=lzo (I'm using Ubuntu Natty). I think the move to use lzo compression by default is a good thing, since: - it's superior performance-wise to zlib - btrfs is not really recommended (yet) for production uses, so it's valid enough to assume users brave enough to use btrfs will know the necessary workarounds (like having separate /boot, or temporary remount with -o compress=zlib when upgrading kernel) - even if by accident you ended with unbootable system due to lzo, you can fix it using livecd and btrfs filesystem defragment to force the needed files to be uncompressed/compressed with zlib. i'd agree with the LZO default and everything else you've said, but i was bitten by this too :-) in my case however, i was using syslinux, and even though /boot was not compressed syslinux still failed with something like: Found compressed data! cannot continue! ... or similar, i don't recall exactly. funny thing is, if i typed out the full kernel boot line (which was super annoying for about a week until i updated to a separate /boot) the system would start up just fine ... so i don't know if syslinux was checking the incompat bit or what, but it failed even though the files themselves were technically ok. something for others to keep in mind at the least. 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: strange btrfs sub list output
On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas stephane_chaze...@yahoo.fr wrote: 2011-05-27 13:49:52 +0200, Andreas Philipp: [...] Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though. If I do: btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance? In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path data while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 So I did manage to get a volume with a parent other than 5, but I did not ask for it. [...] Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken. What's your opinion on this? [...] Given that I don't really get what the parent-child relationship means in that context, I can't really comment. In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional data volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list. It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again. i'm actually really interested in the conclusion to this thread because i _want_ to create subvols with a new parent ... i didn't realize this wasn't possible (nor the mount option) until reading this thread. this would give me a little more flexibility with initcpio hooks and the like vs. packing the btrfs root with tons of hidden files [subvols] or using IDs directly ... i tried absolutely everything i could think of to reproduce this but all subvols ended up having a top level id of `5`. ... so, is there any known way to _purposefully_ create parented subvols with the current tools? -- 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: strange btrfs sub list output
On Tue, May 31, 2011 at 2:32 PM, C Anthony Risinger anth...@xtfx.me wrote: On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp philipp.andr...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31.05.2011 19:40, C Anthony Risinger wrote: On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas stephane_chaze...@yahoo.fr wrote: 2011-05-27 13:49:52 +0200, Andreas Philipp: [...] Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though. If I do: btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance? In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path data while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 So I did manage to get a volume with a parent other than 5, but I did not ask for it. [...] Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken. What's your opinion on this? [...] Given that I don't really get what the parent-child relationship means in that context, I can't really comment. In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional data volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list. It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again. i'm actually really interested in the conclusion to this thread because i _want_ to create subvols with a new parent ... i didn't realize this wasn't possible (nor the mount option) until reading this thread. this would give me a little more flexibility with initcpio hooks and the like vs. packing the btrfs root with tons of hidden files [subvols] or using IDs directly ... i tried absolutely everything i could think of to reproduce this but all subvols ended up having a top level id of `5`. ... so, is there any known way to _purposefully_ create parented subvols with the current tools? Hopefully, I can help clarify this a little bit. In fact, this is the 'usual' case. With the attached patch to the master branch of btrfs-progs-unstable you can 'watch' how the btrfs subvolume list command builds the full path of the listed subvolumes. Additionally, it gives you the IDs of the parent subvolumes. See the following example. ID 256 top level 5 path test1 ID 257 top level 256 path test1.1 ID 257 top level 5 path test1/test1.1 ID 258 top level 5 path test2 ID 259 top level 258 path test2.1 ID 259 top level 5 path test2/test2.1 - From the second line you see that subvolume ID 256 really is ID 257's parent. Additionally, only test1 and test2 have parent ID 5 or in your terminology are in the btrfs root. aaah, ok ... this is what i thought was happening too after taking a peek at the sources (albeit i don't write any C) and seems to match what Hugo was saying if i understand him correctly. this also makes sense what you said about a broken link ... since normally the `btrfs` tool will not let you remove a subvol that has other subvols nested within it ... though *technically* it does not seem to matter, yes? must have been a fluke/bug in the `btrfs` tool where a higher level subvol was removed before it's child somehow, is this correct? or is the FS itself slightly broken when this happens? yeah i know that's kind of my terminology :-) ... i've spent a lot of time explaining btrfs concepts to others and that term always seemed to makes the most sense to people ... `top-level` can change, `default` can change, etc, etc ... but `the btrfs root` can only mean one thing -- the most bottomest of the bottom (or top, if you prefer :-) i'll try this out later tonight, thanks. after booting the correct kernel in KVM, this works exactly as advertised by the commit that added it, and by your explanation -- thanks -- this will be of much use wrt designing sub-root layouts for advanced initramfs recovery options ... i always felt limited by the requirement to be in the btrfs root, and mounting by id looses some flexibility, eg. when trying to use names like pointers/symlinks. ... now i can put subvols anywhere, and user/script only needs to determine the stable parent ids once. nice ... to the laboratory! -- 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
filesystem seeding ... BUGs on .38, .39, loopback, real devices, tmp branch ... everything
hello, i'm trying to setup a seeded FS -- was only able to find this: http://thread.gmane.org/gmane.comp.file-systems.btrfs/10529 ... and announcement-like info from 2009 or so. i keep hitting bugs/oops, and even though the FS *appears* to work correctly afterwards, sometimes mount/strace/etc will hang (could only be .38 here). i tried with loop devices at first, then real devices -- this is all under KVM/QEMU, and with FSs that are/will be smaller than 1G. i've tried with .38, .39, mixed blocks groups, the `tmp` branch from btrfs-progs, and everything else i can think of ... what am i doing wrong? are these known problems (per the other thread ...)? what is the correct way to seed a filesystem? `btrfs filesystem show` reports the FS as missing a device ... but it seems to mount fine. the operation appears to spawn a whole new FS with the same label -- would anyone mind elaborating more? i used the --rootdir feature of mkfs.btrfs to populate the image with ~100MB of barebone filesystem. the `mtime` of the seeded image never changes, so it *seems* to be working ... but i dont understand how to reuse this image or what's really going on (per my above questions :-). ... procedures follow along with the oops it produces; let me know what, if anything, else i should try. i get similar results no matter what i attempt, so i only included the one for now. thanks, C Anthony 2.6.39, loopback, `tmp` branch - #!/bin/bash mkdir ro rw truncate -s700MB output.img.rw mkfs.btrfs -M -r /root/btrfs/fs -m raid0 -d raid0 -L _btrfs_ro_seed btrfstune -S1 output.img losetup /dev/loop0 output.img losetup /dev/loop1 output.img.rw mount /dev/loop0 ro btrfs device add /dev/loop1 ro # !!! BUG !!! mount /dev/loop1 rw echo there ro/hi # FAILS: Read-only filesystem echo there rw/hi # SEEMS TO WORK ... - # btrfs filesystem show - Label: '_btrfs_ro_seed' uuid: 1f29a49c-e437-4329-ac81-d50adea03688 Total devices 1 FS bytes used 97.29MB devid1 size 256.00MB used 169.96MB path /dev/loop0 Label: '_btrfs_ro_seed' uuid: 5824e2ce-6008-4d6d-8e1a-a5b6621214ac Total devices 2 FS bytes used 97.29MB devid2 size 667.57MB used 82.75MB path /dev/loop1 *** Some devices missing Btrfs v0.19-50-ge6bd18d-dirty - START OOPS - [ 2808.826972] device label _btrfs_ro_seed devid 1 transid 13 /dev/loop0 [ 2808.832205] device label _btrfs_ro_seed devid 1 transid 13 /dev/loop0 [ 2808.834058] btrfs: disk space caching is enabled [ 2808.906916] [ cut here ] [ 2808.907673] WARNING: at fs/btrfs/extent-tree.c:5790 btrfs_alloc_free_block+0x1ec/0x330 [btrfs]() [ 2808.908981] Hardware name: Bochs [ 2808.909604] Modules linked in: btrfs zlib_deflate crc32c libcrc32c loop ipv6 ext2 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd uhci_hcd i2c_piix4 psmouse floppy ehci_hcd processor soundcore snd_page_alloc pcspkr evdev button usbcore serio_raw sg i2c_core ext4 mbcache jbd2 crc16 sr_mod cdrom pata_acpi ata_piix libata scsi_mod virtio_rng virtio_pci virtio_net virtio_console virtio_blk virtio_balloon virtio_ring virtio [ 2808.920256] Pid: 2695, comm: btrfs Tainted: G D W 2.6.39-ARCH #1 [ 2808.921097] Call Trace: [ 2808.921724] [810577da] warn_slowpath_common+0x7a/0xb0 [ 2808.922532] [81057825] warn_slowpath_null+0x15/0x20 [ 2808.923371] [a036c74c] btrfs_alloc_free_block+0x1ec/0x330 [btrfs] [ 2808.924257] [a039f337] ? read_extent_buffer+0xd7/0x1e0 [btrfs] [ 2808.925134] [a0358d19] __btrfs_cow_block+0x159/0x890 [btrfs] [ 2808.925992] [a0359563] btrfs_cow_block+0x113/0x350 [btrfs] [ 2808.926863] [a035ef82] btrfs_search_slot+0x1d2/0x9f0 [btrfs] [ 2808.927736] [a039a202] ? free_extent_state+0x32/0x50 [btrfs] [ 2808.928589] [a0360930] btrfs_insert_empty_items+0x70/0xd0 [btrfs] [ 2808.929455] [a03609f0] btrfs_insert_item+0x60/0xe0 [btrfs] [ 2808.930323] [a036e40c] btrfs_make_block_group+0x25c/0x2d0 [btrfs] [ 2808.931204] [a03a41c4] __btrfs_alloc_chunk+0x524/0x970 [btrfs] [ 2808.932083] [a03a4874] init_first_rw_device+0x74/0x130 [btrfs] [ 2808.932945] [813c95a9] ? __mutex_lock_slowpath+0x239/0x320 [ 2808.933805] [a03a6512] btrfs_init_new_device+0x642/0xcd0 [btrfs] [ 2808.934669] [a03ac128] ? btrfs_ioctl+0x7c8/0xa20 [btrfs] [ 2808.935519] [a03ac14a] btrfs_ioctl+0x7ea/0xa20 [btrfs] [ 2808.936328] [81174d8e] ? __blkdev_put+0x1ee/0x200 [ 2808.937151] [8115264e] do_vfs_ioctl+0x8e/0x500 [ 2808.937938] [8115ec2a] ? mntput+0x1a/0x30 [ 2808.938710] [81142927] ? fput+0x167/0x210 [ 2808.939458] [81152b51] sys_ioctl+0x91/0xa0 [ 2808.940236] [813cb312]
Re: filesystem seeding ... BUGs on .38, .39, loopback, real devices, tmp branch ... everything
On Thu, Jun 2, 2011 at 6:40 AM, Geoff Ritter geoff.rit...@gmail.com wrote: On Thu, 2011-06-02 at 04:20 -0500, C Anthony Risinger wrote: i tried with loop devices at first, then real devices -- this is all under KVM/QEMU, and with FSs that are/will be smaller than 1G. I have tried the seed option as well. I was able to successfully mount the read write partition after setting up the seed. However, both had to be independent partitions on a real device. During testing, both .38 and .39rc could NOT create a seed if one or both partitions were encrypted. I believe encrypted partitions also work with a loop device for the unlocked version you write too. The response I got after a few days is as follows: Chris Mason chris.ma...@oracle.com cwillu cwi...@cwillu.com date Thu, May 5, 2011 at 4:42 PM Ok, looks like I busted the seed support when I fixed up some of the chunk allocations. I'll reproduce this and work out a fix. I just assumed it would take a while to fix so I haven't tried again since. If the root of the problem appears to be loop devices, you might want to report that. Err I guess you did. To me, this doesn't explain why it wouldn't work in a Virtual Machine. I would have thought the VM would treat it as a real device. yeah ... i wasn't sure if this was the same exact problem you had or what, i can't find much info at all about anyone using seed support. i tried loop devices on my real machine too (.38), and because of continuous oops/locks i moved to a VM so i didn't hose my system. however, when i tried with real devices in the VM, these were not loopbacks, they were just regular raw files used as backing for QEMU (though i don't know if it internally uses loopback) ... they were exposed as virtio devices /dev/vdb and /dev/vdc. i got the exact same results using those devices, using btrfs-vol instead of btrfs, and a whole slew of other trial and error that all led to the same issue. the 10 lines or so i provided earlier reproduces consistently for me ... in the end, it *seemed* to work, but still :-) what i REALLY want though, is simply more information on how seeding works and should be used ... the wiki et al seem to imply that i can reuse the seed device for MULTIPLE filesystems ... how can i do this? i tried adding the device to an existing array but i couldnt see any files ... can anyone shed some light on this feature? thanks much, 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: Issues with KVM
On Fri, Jul 22, 2011 at 2:44 PM, Victor Stinner victor.stin...@haypocalc.com wrote: Hi, I have a new fast computer to run many virtual machines. Everything looks very fast, except the installation of new operating systems in KVM. The installation is very fast until it begins to write on disk. It looks like it writes slower and slower. I tried Debian, FreeBSD, OpenIndiana and OpenBSD: same problem. The FreeBSD installer displays the speed: it starts at 780 KB/sec (which it already very slow) to finish between 1 and 8 KB/sec. ) is the host FS btrfs? ) are virtio modules in the initramfs (or kernel probably)? ) are you sure virtio is being used (eg. are the disks called vdX vs sdX)? ) is the disk bus set to virtio (virtmanager)? ) is the disk's cache mode set to none [or maybe writeback] (virtmanager)? ) is the disk's storage format set to raw, should be (virtmanager)? ) is caching enabled on the image? () probably need to change the cache mode on the disk, or if the host is btrfs you need to flag the image with whetever is needed to prevent continuous COWing. 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: Issues with KVM
On Fri, Jul 22, 2011 at 2:59 PM, C Anthony Risinger anth...@xtfx.me wrote: On Fri, Jul 22, 2011 at 2:44 PM, Victor Stinner victor.stin...@haypocalc.com wrote: ) is caching enabled on the image? () oops, disregard that ... remainder left over from editing copy/paste :-) 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: [PATCH] btrfs: do not allow mounting non-subvolumes via subvol option
On Wed, Aug 3, 2011 at 1:47 PM, David Sterba d...@jikos.cz wrote: On Sat, Jul 30, 2011 at 12:16:44AM +0800, Zhong, Xin wrote: I believe I have submit a similar patch months ago: http://marc.info/?l=linux-btrfsm=130208585106572w=2 You did! I was not aware of that. I believe adding a helper make things more clear (if it were used all over the code). Hope it can be integrated this time, :-). mehopes too i corrupted an FS after doing this back in Nov of last year (though i was also --bind mounting it after the fact) http://marc.info/?l=linux-btrfsm=129091436915724w=2 ...and a patch proposed: http://marc.info/?l=linux-btrfsm=129091815217860w=2 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: BTRFS partition won't mount
On Wed, Aug 3, 2011 at 3:50 PM, Hugo Mills h...@carfax.org.uk wrote: Try the instructions on the wiki at [1]. (And please feed back and/or fix any issues you have with the instructions -- they're still quite new and probably have awkward corners). [1] https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_can.27t_mount_my_filesystem.2C_and_I_get_a_kernel_oops.21 this worked perfectly for me ... just saved my night from tedious restoration :-) im on kernel 3.0.1 -- hard poweroff led to that problem. i haven't had any issues for some time ... im not sure what the problem was exactly, but sometimes systemd gets a little twacky and takes a year to shutdown ... guess i got a little impatient :-) anyways, thanks for the integration work! -- 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: BTRFS partition won't mount
On Mon, Aug 8, 2011 at 10:54 PM, C Anthony Risinger anth...@xtfx.me wrote: On Wed, Aug 3, 2011 at 3:50 PM, Hugo Mills h...@carfax.org.uk wrote: Try the instructions on the wiki at [1]. (And please feed back and/or fix any issues you have with the instructions -- they're still quite new and probably have awkward corners). [1] https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_can.27t_mount_my_filesystem.2C_and_I_get_a_kernel_oops.21 this worked perfectly for me ... just saved my night from tedious restoration :-) im on kernel 3.0.1 -- hard poweroff led to that problem. i haven't had any issues for some time ... im not sure what the problem was exactly, but sometimes systemd gets a little twacky and takes a year to shutdown ... guess i got a little impatient :-) anyways, thanks for the integration work! well i tried to shutdown again and had to force poweroff via `echo b /proc/sysrq-trigger` (but this time it was because dbus segfaulted and i couldnt ask systemd to reboot ... `kill -INT 1` wasn't working either, maybe all systemd related) ... the same thing happened again. i'm wondering if btrfs is causing the hang to begin with? i will watch it after i fix it tonight by making systemd more verbose and see what it has to say. im wondering: ) what else i could try to determine if btrfs is contributing to the issue ) any other more graceful options than `echo b /proc/sysrq-trigger` exist thanks, -- 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: licenses (for apple OSX and others)?
On Sun, Aug 14, 2011 at 9:53 PM, Billy Crook billycr...@gmail.com wrote: On Sun, Aug 14, 2011 at 19:34, ivo welch ivo...@gmail.com wrote: curiosity question---could btrfs be licensed in multiple ways to allow Apple and other vendors to adopt it? Great question, Ivo. And it turns out, btrfs is already licensed to permit commercial use, integration into other products, and resale. The license of btrfs isn't stopping Apple or Microsoft from using btrfs. All licenses have terms (You should read the terms on some of Apple and Microsoft's software), but so long as they don't violate any terms, they are welcome to use all parts of the btrfs code for their corporation's profit, and their customer's benefit. ... and while some will certainly argue one way or another, this is a case where (IMO) the code for btrfs (as a module) is clearly distinct from the OSX kernel (as it was not even designed for it originally) and would not constitute far reaching public release of Apple IP ... though tbh i know nothing about OSX kernel and whether it support things like dynamic modules, so i could be mistaken ... ... but im confident there is a way Apple could wire it up so IP release could be very small or nonexistent. or maintain a port if they so wished. the real question is whether or not they would even desire using it with infrastructure around HFS+/etc ... in my observations Apple and friends are incredibly ... ehm ... selective -- the hardware and everything above it *must* have the `Seal of Approval` -- maybe to reduce/isolate their problem pool or maintain it's clique-crazed chic aura :-), i dont know, but it's not for the end-user's flexibility -- that's for sure. the glaring example to me is virtually the entire mobile/handheld/device industry deciding on micro-USB as the power+data xchange connection *except* one infamous product line ... but meh, who really knows anyway; it certainly would be incredibly cool to have a common denominator greater than FAT, especially since commodity flash chips are 8-16GB now. -- 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: Btrfs moved my root tree off the end of the device
On Wed, Sep 7, 2011 at 6:33 PM, Justin Gottula jus...@jgottula.com wrote: Hi, I recently created a Btrfs volume on top of a software (mdadm) raid5 array (since Btrfs currently lacks raid5 support at the FS level). On this 640 GB volume, I stored a ~400 GB tar file. After a couple weeks of use, I used 'btrfs defragment' on this file in an effort to (a) defrag and (b) compress the file. I made sure I was using the latest version of the userspace utilities (Btrfs v0.19-35-g1b444cd-dirty) as well as kernel 3.0. did you use the integration branch, ie: http://git.darksatanic.net/repo/btrfs-progs-unstable.git ... this has the latest code for the time being. looks like `integration-20110805` is the most recent head. snip At this point, I took a disk image and dived in, and in doing so discovered that somehow, there were CHUNK_ITEMs in the chunk tree that referred to physical address ranges that were entirely outside of the device (matching up to the ranges showing up in the kernel log over and over). Evidently, the filesystem driver thought it should move the root tree onto a chunk that existed at a nonexistant offset in the device. I checked the superblocks and verified that the total_bytes fields matched up correctly to the actual device size, which leaves me wondering how those chunks ever got there. i could be way of base here, but your report reminded me of: [thread] http://www.spinics.net/lists/linux-btrfs/index.html#12121 --- extent data backref root 5 objectid 258 offset 18446744073709543424 count 1 extent data backref root 5 objectid 257 offset 0 count 1 So I think we have to live with this defect, just fix relocation for the negative offset case ? I prefer fixing relocation. --- ... which, if i understood correctly, surfaced some issues with relocation that could cause the offset to be grossly inaccurate (eg. off the device completely?) could of course be completely unrelated :-) -- 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: mount a multi-device filesystem using a loopback device
On Wed, Sep 7, 2011 at 1:44 AM, Jeff Liu jeff@oracle.com wrote: On 09/07/2011 12:37 PM, cwillu wrote: 1. Create and format two images, the 1st in 400Mbytes, and 2nd in 286Mbytes. root@pibroch:/btrfs-progs# ls -lh /usr/src/linux-3.0/img* -rw-r--r-- 1 jeff jeff 400M 2011-09-07 12:00 /usr/src/linux-3.0/img0 -rw-r--r-- 1 jeff jeff 286M 2011-09-07 12:00 /usr/src/linux-3.0/img1 Very small btrfs filesystem require special handling, mixed block groups in particular, which I believe also requires an updated mkfs from the integration repo. Thanks for your response, however, even if I enlarged the image size to 2G, still got no luck. Per Zefan's comments, run 'btrfs device scan' fixed this issue. you should be able to achieve this via `device=` mount option(s?) as well: https://btrfs.wiki.kernel.org/index.php/Getting_started#Mount_Options ... for completeness :-) ... and posterity or whatever. 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: snapshot issues
On 10/14/2011 12:13 PM, Jim wrote: Good afternoon btrfs, I have been having issues with snapshots not reading the whole file tree below them. I have installed new btrfs-progs from git://git.darksatanic.net/repo/btrfs-progs-unstable.git made and installed them. My tree is: /Btrfs | |__ nfs1 | |__ data | |__ sites | |__ 00xx | |__ email@address If I use btrfsctl -s (btrfs sub snapshot isn't working) snappath-name /btrfs/nfs1 I get a mountable snapshot of nfs1 but data is all that I can see below it. If I btrfsctl -s snappath-name /btrfs/nfs1/data/sites/ I can mount / and get a full list of email@address accounts but none of the files below them. I should have stated earlier, everything down to and including /email@address are subvolumes. Below /email@address directories and files were rsync'd into the subvol from an nfs mount. Finally if I snapshot /email@address I have access to all directories and files below them. Because of this I believe that the issue is with snapshots of subvolumes. I thought I just couldn't see subvols above the snapshot level and was able to see subvols below. Am I confused or is this a real problem. I am using kernel 3.1.0-rc4 and will be happy to trace anything you need if you can tell me how to get what you need. Thanks for your help. Jim -- 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 yaarg -- resend w/list included -- changed clients recently (tbird) and cant figure out how to default to replay-all ... i believe this is expected behavior as of now -- there are a couple threads mentioning `recursive snapshotting`, check those out. AFAIK a snapshot will not traverse beyond it's own boundaries. -- C Anthony Risinger -- 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
list subvolumes with new btrfs command
hello,
i maintain an unofficial initrd hook in Arch Linux that allows BTRFS
to be used as the root device. i am trying to update the hook to use
the more extensive btrfs command, adding support for users to change
their default subvolume from within the initrd (i'm creating a sort of
rollback feature, in conjunction with automatic snapshotting via the
package manager), and adding support for hot spares (via a second
BTRFS pool in which devices are stolen to repair the primary array).
anyways, i'm having trouble getting a listing of subvolumes:
$ btrfs subvolume list /
ERROR: can't perform the search
the machine has a BTRFS root. i have also tried creating a snapshot
and pointing the command at that, but i get the same results. am i
using the command wrong? relevant code is from btrfs-list.c:
ret = ioctl(fd, BTRFS_IOC_TREE_SEARCH, args);
if (ret 0) {
fprintf(stderr, ERROR: can't perform the search\n);
return 0;
}
kernel:
$ uname -r
2.6.33-ARCH
is there a new CONFIG_* kernel parameter that needs to be set since
2.6.32? everything seems to be in order and working fine... any help
appreciated.
thanks,
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: list subvolumes with new btrfs command
need super root? in my ubuntu10.04 with latest btrfs-progs: $ ./btrfs subvolume list /media/sda3-100g/ ERROR: can't perform the search $ sudo ./btrfs subvolume list /media/sda3-100g/ ID 258 top level 5 path misc/snap/snap-4-26 ah sorry, i forgot to mention that it doesn't work as super user either, same result: $ sudo btrfs subvolume list / ERROR: can't perform the search the btrfs-progs in ubuntu is probably slightly behind git HEAD (what i'm using in Arch package), maybe it broke recently, i might try to bisect and see it i can pinpoint to problem commit. i am also using kernel 2.6.33 (ubuntu is .32 i think) that's why i thought maybe there was an issue there; it seems like the ioctl() call is failing no matter what in my case. other details i can think of: 1) filesystem was created by a 2.6.31 kernel i will use loopback + BTRFS to test what is happening here and report back; maybe i can't scan / ...? thanks for the response, any other input is very much appreciated. thanks, 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: list subvolumes with new btrfs command
I am using ubuntu-10.04-rc with kernel compiled from the almost lastest source , the btrfs-progs is latest too. You can modify line fprintf(stderr, ERROR: can't perform the search\n); to fprintf(stderr, ERROR: can't perform the search: %s\n, strerror(errno)); to see what happened on earth. nice: $ sudo btrfs subvolume list / ERROR: can't perform the search: Inappropriate ioctl for device i'm not really familiar with C, or anything this low level, does this help you diagnose my problem? thanks again for the help thus far, 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: list subvolumes with new btrfs command
On Mon, Apr 26, 2010 at 12:58 PM, Hubert Kario h...@qbs.com.pl wrote: On Monday 26 April 2010 19:23:21 C Anthony Risinger wrote: I am using ubuntu-10.04-rc with kernel compiled from the almost lastest source , the btrfs-progs is latest too. You can modify line fprintf(stderr, ERROR: can't perform the search\n); to fprintf(stderr, ERROR: can't perform the search: %s\n, strerror(errno)); to see what happened on earth. nice: $ sudo btrfs subvolume list / ERROR: can't perform the search: Inappropriate ioctl for device i'm not really familiar with C, or anything this low level, does this help you diagnose my problem? Have you tried to run it on the device with the btrfs, not the mount point? It looks like the ioctl was made too restrictive about its arguments. ah yes i missed mentioning that to, tried that: $ sudo btrfs sub list /dev/sda2 ERROR: '/dev/sda2' is not a subvolume no dice :( -- 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: list subvolumes with new btrfs command
On Mon, Apr 26, 2010 at 2:10 PM, C Anthony Risinger anth...@extof.me wrote: On Mon, Apr 26, 2010 at 12:58 PM, Hubert Kario h...@qbs.com.pl wrote: On Monday 26 April 2010 19:23:21 C Anthony Risinger wrote: I am using ubuntu-10.04-rc with kernel compiled from the almost lastest source , the btrfs-progs is latest too. You can modify line fprintf(stderr, ERROR: can't perform the search\n); to fprintf(stderr, ERROR: can't perform the search: %s\n, strerror(errno)); to see what happened on earth. nice: $ sudo btrfs subvolume list / ERROR: can't perform the search: Inappropriate ioctl for device i'm not really familiar with C, or anything this low level, does this help you diagnose my problem? Have you tried to run it on the device with the btrfs, not the mount point? It looks like the ioctl was made too restrictive about its arguments. ah yes i missed mentioning that to, tried that: $ sudo btrfs sub list /dev/sda2 ERROR: '/dev/sda2' is not a subvolume no dice :( i tried setting up loopback with a newly formatted btrfs image + mounting, same result: Inappropriate ioctl for device. same error whether i point the command at the default subvolume or a snapshot. is there anything (missing) i should check in regards to my kernel (module/progs mismatch)? -- 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: list subvolumes with new btrfs command
On Mon, Apr 26, 2010 at 3:51 PM, C Anthony Risinger anth...@extof.me wrote: On Mon, Apr 26, 2010 at 2:10 PM, C Anthony Risinger anth...@extof.me wrote: On Mon, Apr 26, 2010 at 12:58 PM, Hubert Kario h...@qbs.com.pl wrote: On Monday 26 April 2010 19:23:21 C Anthony Risinger wrote: I am using ubuntu-10.04-rc with kernel compiled from the almost lastest source , the btrfs-progs is latest too. You can modify line fprintf(stderr, ERROR: can't perform the search\n); to fprintf(stderr, ERROR: can't perform the search: %s\n, strerror(errno)); to see what happened on earth. nice: $ sudo btrfs subvolume list / ERROR: can't perform the search: Inappropriate ioctl for device i'm not really familiar with C, or anything this low level, does this help you diagnose my problem? Have you tried to run it on the device with the btrfs, not the mount point? It looks like the ioctl was made too restrictive about its arguments. ah yes i missed mentioning that to, tried that: $ sudo btrfs sub list /dev/sda2 ERROR: '/dev/sda2' is not a subvolume no dice :( i tried setting up loopback with a newly formatted btrfs image + mounting, same result: Inappropriate ioctl for device. same error whether i point the command at the default subvolume or a snapshot. is there anything (missing) i should check in regards to my kernel (module/progs mismatch)? bleh, looks like my kernel didn't have what it needed; i thought 2.6.33/stock Arch kernel was recent enough. i booted an 2.6.34rc5 kernel any everything works now: $ sudo btrfs sub list / ID 259 top level 5 path vps/var/lib/vps-lxc/tpl/arch-nano ID 260 top level 5 path vps/var/lib/vps-lxc/dom/dom1 heh, i forgot about those snapshots :-). i will compensate for this possibility in my initrd hook. apologies for the noise. on a parting note, the strerror(errno) was a nice change, and might be a useful addition for others, as it also pointed my in the right direction for permission problems (without sudo/non-super): $ btrfs sub list / ERROR: can't perform the search: Operation not permitted other than that, thanks for the assistance; the new btrfs tool is nice. 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
default subvolume abilities/restrictions
hi, i'm working on an initrd hook [http://aur.archlinux.org/packages.php?ID=33376] to support non-volatile system rollbacks (promoting a temporary rollback snapshot to the new active/default). when the system is installed to the default/. subvolume (as many users probably initially do), it is more difficult/messier to manage system state; there are empty folders in each child snapshot where a subvolume used to exist (this seems like BUG to me, dir should not exist?) in the default subvolume. these grow/vary with time. to work around this and for cleaner implementation, i'll intend to permanently boot a named subvolume [__active] (though its contents may be swapped out). ultimately, i have to tell the user to manually remove the old junk (/usr, /etc, /var, etc...) from the default subvolume (since its really in the /__active subvolume) moving along to a question... can the default subvolume be swapped/removed/renamed/popped/shifted? what would have been useful, would be the ability to generate an empty, parent subvolume to _contain_ the current one, and rename it to __active. btrfs gives rise to a subroot structure; the structure beneath the root. is something like this possible or can be added? an alternative idea i had was promoting a subvolume to be the new root, and anything above the new root is lost/forgotten. then i could create the subroot structure in a subvol, snapshot the default subvol to where i want it, and promote the subvol to be the new root. like a permanent pivot_root/chroot. great stuff, 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: default subvolume abilities/restrictions
On Wed, May 19, 2010 at 9:20 AM, Chris Ball c...@laptop.org wrote: Hi, moving along to a question... can the default subvolume be swapped/removed/renamed/popped/shifted? I think btrfs subvolume list; btrfs subvolume set-default id path does what you need. - Chris. maybe i'm missing something or not being clear. take the following setup for the . subvol: / /etc /usr /lib if i snapshot / to /__active i now have: / /etc /usr /lib /__active i now btrfs subvolume set-default whatever_the_internal_id_is_for_active /... what happens to the directories /usr, /etc, and /lib that _still_ exist in the . subvol? it's my understanding that setting the default subvol DOES NOT actually do anything except negate the need to use the subvol=id mount option... the . subvolume still exists, still can be mounted independently, still has files in it, and still is a parent the the now default __active subvol and thus CANNOT be removed. can i be confirmed on this reasoning? it seems to me that the original subvolume is somewhat immutable in its location and relation to other, child subvolumes. it's the only one that cannot be placed into a different subvolume; it MUST be the ultimate parent. am i off base here or misinterpreting what set-default actually does (Arch is still on 2.6.33, i can't use set-default yet so i admit i haven't really played with it yet)? i wouldn't think that simply setting a new default is the same as setting a new top-level subvolume; am i wrong? 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
missing include from btrfsck.c?
i'm not a C developer, but i like to think i know enough to be dangerous (pragmatic) :-D building from git master failed with: .. .. gcc -Wp,-MMD,./.btrfsck.o.d,-MT,btrfsck.o -Wall -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -g -Werror -Os -c btrfsck.c cc1: warnings being treated as errors btrfsck.c: In function ‘maybe_free_inode_rec’: btrfsck.c:323:2: error: implicit declaration of function ‘S_ISDIR’ btrfsck.c:328:2: error: implicit declaration of function ‘S_ISREG’ btrfsck.c:328:2: error: implicit declaration of function ‘S_ISLNK’ make: *** [btrfsck.o] Error 1 grepping the source turned up several other files successfully using those functions. after a quick serach, it looked to be a part of stat... and the other files were all including sys/stat.h. i'm not sure if it's my gcc being paranoid (archlinux), but adding: #include sys/stat.h to btrfsck.c fixed the issue for me. 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: default subvolume abilities/restrictions
On Wed, May 19, 2010 at 9:01 AM, C Anthony Risinger anth...@extof.me wrote: .. i need a way, programmatically and safely, to move the users installation from the original subvolume into an isolated subvolume .. or to generate a new, empty default/root subvolume and place the current default subvol (.) _into_ it... how can this be done? can any devs out there make this happen? note, what i'm looking for is _not_ setting the default subvolume to be mounted, but actually moving/renaming the default (.) subvolume itself. essentially, can we get a command to do this: # btrfs subvolume create new_root # mv . new_root/old_root that unsurprisingly fails with: mv: cannot move `.' to `new_root/old_root': Device or resource busy could we extend btrfs-progs tools to allow something like this? does the on disk format support _moving_ the default subvol? this operation is critical to upgrade a user who has installed their system into the default subvol, as most naturally would. clean rollback systems/structures depend on the user having his system installed to an isolated subvol, NOT the default. what sayith you? thanks, C Anthony additionally, is anything like the following on a TODO list anywhere? thanks again. ps. a recursive snapshotting tool could be useful too (if / and /home were both subvols, the tool would create both when / was snapped, instead of /home being an empty folder in the snapshot [BUG?]). -- 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: Music-files suddenly not recognized anymore, empty files - Btrfschk reports errors
On Sat, Jun 12, 2010 at 3:40 PM, Clemens Eisserer linuxhi...@gmail.com wrote: Hi, Recently Amarok started to reject some of music files. Some files seem to be simply corrupted (mplayer is still able to play them), other have zero length. Btrfsck reports: root 5 inode 1371 errors 400 found 42498768896 bytes used err is 1 total csum bytes: 41015664 total tree bytes: 498728960 total fs tree bytes: 406466560 btree space waste bytes: 110792472 file data blocks allocated: 271306133504 referenced 46886879232 Btrfs Btrfs v0.19 Anything I can do to repair those errors? have you taken any snapshots? you could pull them from there maybe. btrfsck is not able to repair anything yet. -- 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: default subvolume abilities/restrictions
On Sat, Jun 12, 2010 at 12:24 AM, C Anthony Risinger anth...@extof.me wrote: On Wed, May 19, 2010 at 9:01 AM, C Anthony Risinger anth...@extof.me wrote: .. i need a way, programmatically and safely, to move the users installation from the original subvolume into an isolated subvolume .. or to generate a new, empty default/root subvolume and place the current default subvol (.) _into_ it... how can this be done? can any devs out there make this happen? note, what i'm looking for is _not_ setting the default subvolume to be mounted, but actually moving/renaming the default (.) subvolume itself. essentially, can we get a command to do this: # btrfs subvolume create new_root # mv . new_root/old_root that unsurprisingly fails with: mv: cannot move `.' to `new_root/old_root': Device or resource busy could we extend btrfs-progs tools to allow something like this? does the on disk format support _moving_ the default subvol? this operation is critical to upgrade a user who has installed their system into the default subvol, as most naturally would. clean rollback systems/structures depend on the user having his system installed to an isolated subvol, NOT the default. what sayith you? i might even try to implement this myself... can i at least get confirmation that the above is possible? all i want to do is create a new/empty subvol, put the old top-level subvol inside it, and make the empty subvol the new root. this lets me put a users installation INTO a subvol even though they originally installed the system into the root subvol. guidance please? chris? :-) thanks, 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: default subvolume abilities/restrictions
On Sat, Jun 12, 2010 at 7:22 PM, David Brown bt...@davidb.org wrote: On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wrote: # btrfs subvolume create new_root # mv . new_root/old_root can i at least get confirmation that the above is possible? I've had no problem with # btrfs subvolume snapshot . new_root # mkdir old_root # mv * old_root # rm -rf old_root Make sure the 'mv' fails fo move new_root, and I'd look at the new_root before removing everything. David heh, yeah i as i was writing the last email i realized that all i really wanted was to: # mv * new_root for some reason i was convinced that i must snapshot the old_root (.) to new_root... and then remove the erroneous stuff from old_root (.). thus a way to parent the default subvol (old_root/.) seemed a better solution... but alas, a snapshot isn't necessary. i can create an empty subvol new_root, and then mv * new_root. i don't know how that escaped me :-), sorry for all the noise. however, there probably is a legitimate use case for wanting to replace the default subvolume, but this isn't it. 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: default subvolume abilities/restrictions
On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger anth...@extof.me wrote: On Sat, Jun 12, 2010 at 7:22 PM, David Brown bt...@davidb.org wrote: On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wrote: # btrfs subvolume create new_root # mv . new_root/old_root can i at least get confirmation that the above is possible? I've had no problem with # btrfs subvolume snapshot . new_root # mkdir old_root # mv * old_root # rm -rf old_root Make sure the 'mv' fails fo move new_root, and I'd look at the new_root before removing everything. David heh, yeah i as i was writing the last email i realized that all i really wanted was to: # mv * new_root for some reason i was convinced that i must snapshot the old_root (.) to new_root... and then remove the erroneous stuff from old_root (.). thus a way to parent the default subvol (old_root/.) seemed a better solution... but alas, a snapshot isn't necessary. i can create an empty subvol new_root, and then mv * new_root. i don't know how that escaped me :-), sorry for all the noise. however, there probably is a legitimate use case for wanting to replace the default subvolume, but this isn't it. C Anthony ok i take it all back, i DO need this... i rewrote my initramfs hook to do the following operations: # btrfs subvolume create /new_root # mv /* /new_root instead of what i had: # btrfs subvolume snapshot / /new_root and it resulted in scarily COPYING my entire system... several gigs worth... to the newly created subvolume, which took forever, and grinded on my HD for awhile. i don't know how long because i went to bed. this is why i need a way to parent the default subvolume. a snapshot is nice and quick, but it leaves / full of erroneous folders (dev/etc/usr/lib), an entire system, that will no longer be used. this space will in time become dead wasted space unless my users manually rm -rf themselves. so... any input on this? how can i effectively, and efficiently, move a users installation into a dedicated subvolume, when they have already installed into the default subvolume? i think the best way is what i originally suggested; make an empty subvolume the new top-level subvol, and place the old top-level subvol INTO it with a new name. thoughts? 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: default subvolume abilities/restrictions
On Sun, Jun 13, 2010 at 12:47 PM, C Anthony Risinger anth...@extof.me wrote: On Sat, Jun 12, 2010 at 8:06 PM, C Anthony Risinger anth...@extof.me wrote: On Sat, Jun 12, 2010 at 7:22 PM, David Brown bt...@davidb.org wrote: On Sat, Jun 12, 2010 at 06:06:23PM -0500, C Anthony Risinger wrote: # btrfs subvolume create new_root # mv . new_root/old_root can i at least get confirmation that the above is possible? I've had no problem with # btrfs subvolume snapshot . new_root # mkdir old_root # mv * old_root # rm -rf old_root Make sure the 'mv' fails fo move new_root, and I'd look at the new_root before removing everything. David heh, yeah i as i was writing the last email i realized that all i really wanted was to: # mv * new_root for some reason i was convinced that i must snapshot the old_root (.) to new_root... and then remove the erroneous stuff from old_root (.). thus a way to parent the default subvol (old_root/.) seemed a better solution... but alas, a snapshot isn't necessary. i can create an empty subvol new_root, and then mv * new_root. i don't know how that escaped me :-), sorry for all the noise. however, there probably is a legitimate use case for wanting to replace the default subvolume, but this isn't it. C Anthony ok i take it all back, i DO need this... i rewrote my initramfs hook to do the following operations: # btrfs subvolume create /new_root # mv /* /new_root instead of what i had: # btrfs subvolume snapshot / /new_root and it resulted in scarily COPYING my entire system... several gigs worth... to the newly created subvolume, which took forever, and grinded on my HD for awhile. i don't know how long because i went to bed. this is why i need a way to parent the default subvolume. a snapshot is nice and quick, but it leaves / full of erroneous folders (dev/etc/usr/lib), an entire system, that will no longer be used. this space will in time become dead wasted space unless my users manually rm -rf themselves. so... any input on this? how can i effectively, and efficiently, move a users installation into a dedicated subvolume, when they have already installed into the default subvolume? i think the best way is what i originally suggested; make an empty subvolume the new top-level subvol, and place the old top-level subvol INTO it with a new name. thoughts? can i get a little feedback on this problem? i choke slightly when telling users the only way to clean their old / is by rm -rf'ing everything i need the ability to move the default subvolume into a new, empty subvolume. the empty subvolume then becomes the new default. the end result is moving the users installation into a dedicated subvolume, cleanly and efficiently, so the system can do other things with the subroot structure. the way i am doing it now is snapshotting the users / to /__active... however, the side effect is an entire system worth of files that will in time become dead space. moving the users install via mv into an empty subvol does not work. everything is actually copied = slow,slow,slow. ideas??? how can i parent the default subvol with an empty subvol? this seems a legitimate operation. thanks, 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: Atomic replacement of subvolumes is not possible
On Sat, Jun 26, 2010 at 12:25 PM, Daniel Baumann dan...@debian.org wrote: Hi, this is basically a forward from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587253 rename(2) allows for the atomic replacement of files. Being able to atomically replace subvolume snapshots would be equally invaluable, since it would permit lock-free replacement of subvolumes. % btrfs subvolume snapshot src dest creates dest as a snapshot of src. However, if I want to do the converse, % btrfs subvolume snapshot dest src then dest is snapshotted as src/dest, i.e. not replacing the original subvolume, but going inside the original subvolume. Use case 1: I have a subvolume of data under active use, which I want to periodically update. I'd like to do this by atomically replacing its contents. I can replace the content right now by deleting the old subvolume and then snapshotting the new on in its place, but it's racy. It really needs to be replaced in a single operation, or else there's a small window where there is no data, and I'd need to resort to some external locking to protect myself. Use case 2: In schroot, we create btrfs subvolume snapshots to get copy-on- write chroots. This works just fine. We also provide direct access to the source subvolume, but since it could be snapshotted in an inconsistent state while being updated, we want to do the following: · snapshot source subvolume · update snapshot · replace source volume with updated snapshot Please keep roger in the cc for any replies, thanks. i am also looking for functionality similar to this, except i would like to be able to replace the DEFAULT subvolume, with an empty or existing subvolume, and put the original default subvolume INSIDE the new root (or drop it completely), outlined by this post and the thread it's in: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05278.html is there any feedback on these actions? no one seems to even respond :-( it would seem we need ways to swap subvolumes around, _including_ the default, providing the on-disk format supports such operations. 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: Atomic replacement of subvolumes is not possible
On Wed, Jun 30, 2010 at 8:31 AM, Chris Mason chris.ma...@oracle.com wrote: On Sun, Jun 27, 2010 at 07:44:12PM -0500, C Anthony Risinger wrote: On Sat, Jun 26, 2010 at 12:25 PM, Daniel Baumann dan...@debian.org wrote: Hi, this is basically a forward from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587253 rename(2) allows for the atomic replacement of files. Being able to atomically replace subvolume snapshots would be equally invaluable, since it would permit lock-free replacement of subvolumes. % btrfs subvolume snapshot src dest creates dest as a snapshot of src. However, if I want to do the converse, % btrfs subvolume snapshot dest src then dest is snapshotted as src/dest, i.e. not replacing the original subvolume, but going inside the original subvolume. Use case 1: I have a subvolume of data under active use, which I want to periodically update. I'd like to do this by atomically replacing its contents. I can replace the content right now by deleting the old subvolume and then snapshotting the new on in its place, but it's racy. It really needs to be replaced in a single operation, or else there's a small window where there is no data, and I'd need to resort to some external locking to protect myself. I'm not sure I understand use case #1. The problem is that you'll have files open in the subvolume and you can't just pull the rug out from under them. Could you tell me a little more about what you're trying to do? Use case 2: In schroot, we create btrfs subvolume snapshots to get copy-on- write chroots. This works just fine. We also provide direct access to the source subvolume, but since it could be snapshotted in an inconsistent state while being updated, we want to do the following: · snapshot source subvolume · update snapshot · replace source volume with updated snapshot Please keep roger in the cc for any replies, thanks. i am also looking for functionality similar to this, except i would like to be able to replace the DEFAULT subvolume, with an empty or existing subvolume, and put the original default subvolume INSIDE the new root (or drop it completely), outlined by this post and the thread it's in: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05278.html is there any feedback on these actions? no one seems to even respond :-( it would seem we need ways to swap subvolumes around, _including_ the default, providing the on-disk format supports such operations. Moving 'default' generally involves a reboot for the same reasons. We have to worry about open files and their view of the filesystem. mv on a directory won't affect file handles that are open, and renaming subvolumes needs to follow a similar model. could we fail if the user tries to replace a subvolume while it's being used? what if the root device is _not_ the default (.) subvolume, then can it be swapped? in my use case, i am running in initramfs, so the root device has not even been mounted or pivoted to; it should be safe to do whatever i want to the filesystem. i want to move the user's installation to a dedicated subvolume. what about this: would it be possible to have TWO subvolumes by default? the regular one (current directory, .): mount -o subvol=. btrfs_dev /mnt would behave as it does now. BUT... there would then be a special, permanent (like . is right now) subvol, say parent directory (..): mount -o subvol=.. btrfs_dev /mnt TWO dots would mount the parent of ., where i could then swap out the real default (.). would that work? 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: Atomic replacement of subvolumes is not possible
On Thu, Jul 1, 2010 at 8:30 PM, Chris Mason chris.ma...@oracle.com wrote: On Wed, Jun 30, 2010 at 09:26:11AM -0500, C Anthony Risinger wrote: On Wed, Jun 30, 2010 at 8:31 AM, Chris Mason chris.ma...@oracle.com wrote: On Sun, Jun 27, 2010 at 07:44:12PM -0500, C Anthony Risinger wrote: On Sat, Jun 26, 2010 at 12:25 PM, Daniel Baumann dan...@debian.org wrote: Hi, this is basically a forward from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587253 rename(2) allows for the atomic replacement of files. Being able to atomically replace subvolume snapshots would be equally invaluable, since it would permit lock-free replacement of subvolumes. % btrfs subvolume snapshot src dest creates dest as a snapshot of src. However, if I want to do the converse, % btrfs subvolume snapshot dest src then dest is snapshotted as src/dest, i.e. not replacing the original subvolume, but going inside the original subvolume. Use case 1: I have a subvolume of data under active use, which I want to periodically update. I'd like to do this by atomically replacing its contents. I can replace the content right now by deleting the old subvolume and then snapshotting the new on in its place, but it's racy. It really needs to be replaced in a single operation, or else there's a small window where there is no data, and I'd need to resort to some external locking to protect myself. I'm not sure I understand use case #1. The problem is that you'll have files open in the subvolume and you can't just pull the rug out from under them. Could you tell me a little more about what you're trying to do? Use case 2: In schroot, we create btrfs subvolume snapshots to get copy-on- write chroots. This works just fine. We also provide direct access to the source subvolume, but since it could be snapshotted in an inconsistent state while being updated, we want to do the following: · snapshot source subvolume · update snapshot · replace source volume with updated snapshot Please keep roger in the cc for any replies, thanks. i am also looking for functionality similar to this, except i would like to be able to replace the DEFAULT subvolume, with an empty or existing subvolume, and put the original default subvolume INSIDE the new root (or drop it completely), outlined by this post and the thread it's in: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05278.html is there any feedback on these actions? no one seems to even respond :-( it would seem we need ways to swap subvolumes around, _including_ the default, providing the on-disk format supports such operations. Moving 'default' generally involves a reboot for the same reasons. We have to worry about open files and their view of the filesystem. mv on a directory won't affect file handles that are open, and renaming subvolumes needs to follow a similar model. could we fail if the user tries to replace a subvolume while it's being used? what if the root device is _not_ the default (.) subvolume, then can it be swapped? in my use case, i am running in initramfs, so the root device has not even been mounted or pivoted to; it should be safe to do whatever i want to the filesystem. i want to move the user's installation to a dedicated subvolume. what about this: would it be possible to have TWO subvolumes by default? the regular one (current directory, .): mount -o subvol=. btrfs_dev /mnt would behave as it does now. BUT... there would then be a special, permanent (like . is right now) subvol, say parent directory (..): mount -o subvol=.. btrfs_dev /mnt TWO dots would mount the parent of ., where i could then swap out the real default (.). would that work? We do provide a set-default ioctl that can be used to change the default for the next mount. This is pretty close to what you want, let me think about ways to make it easier to use. that's the thing; set-default is not the effect i need to achieve. now, if there was a way i could use set-default AND promote that subvol to become the real root/default subvol (.), then that would work. maybe as a destructive option to set-default. i need to effectively move the users installation from subvol ., to subvol __active. this is easy with any subvol _except_ (.). without this, the user has a bunch of dead files they will never see, and will eventually consume space. the only way to remove them, as of now, is to tell the user to mount the (.) subvol, and rm -rf bin/lib/usr/etc... because there is no way to manage the . subvol. 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: Atomic replacement of subvolumes is not possible
On Fri, Jul 2, 2010 at 2:38 PM, Goffredo Baroncelli kreij...@gmail.com wrote: On Friday, July 02, 2010, Chris Mason wrote: On Wed, Jun 30, 2010 at 09:26:11AM -0500, C Anthony Risinger wrote: [...] what about this: would it be possible to have TWO subvolumes by default? the regular one (current directory, .): mount -o subvol=. btrfs_dev /mnt would behave as it does now. BUT... there would then be a special, permanent (like . is right now) subvol, say parent directory (..): mount -o subvol=.. btrfs_dev /mnt TWO dots would mount the parent of ., where i could then swap out the real default (.). would that work? We do provide a set-default ioctl that can be used to change the default for the next mount. This is pretty close to what you want, let me think about ways to make it easier to use. -chris Hello Chris, to me it seems that the Anthony request make sense. And it not so difficult to have. We have all the pieces, we need only a policy regarding the subvolume use and a bit of glue It should be sufficent to replace the standard mkfs.btrfs command with the following commands sequence # mkfs.btrfs device # mount device /mnt/tmp # btrfs subvol create /mnt/tmp/__root__ # btrfs subvol set-default __root__ /mnt/tmp/ # umount device So if an user don't want to care about a subvolume, he simply mount a btrfs filesystem without any option. This user will work inside the __root__ subvolume, where he can create snapshot, subvolume... Instead if an user want to play with different root in different subvolumes, he have to mount the ., where he can manage the root-subvolume(s) (renaming, moving, snapshotting/branching ... ). The key is to think the . subvolume only to handling the subvolumes and not to storing files. If you don't want to use it, you can simply ignore it, because the default is to mount the __root__ subvolume. i don't want to comment anymore on this thread, as i feel i kind of hijacked it :-), but what Goffredo has suggested above is a great idea and would solve my default subvol problems completely. the real problem is that users are installing into the . subvol not knowing they cannot easily manipulate the system after that. as Goffredo hinted: The key is to think the . subvolume only to handling the subvolumes and not to storing files. if a empty subvol is created, then marked as the new mount default, users would never know the difference, and integrators like me could still get underneath to prepare the system for all the cool distribution-specific btrfs features. 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: btrfsctl returns bad exit status
Try using btrfs tool; btrfsctl is/will be deprecated I think... and it's better anyway. C Anthony [mobile] On Jul 23, 2010, at 3:04 PM, K. Richard Pixley r...@noir.com wrote: Using btrfsctl from ubuntu maverick, (built and running on ubuntu-10.04), I get: r...@eisenhower btrfsctl -s snap1 /home || echo failed operation complete Btrfs Btrfs v0.19 failed r...@eisenhower ls -las snap1 total 4 4 drwxr-xr-x 1 rootroot32 2010-07-20 18:25 . 0 drwxr-xr-x 1 richrich 1324 2010-07-21 12:47 .. 0 drwxr-xr-x 1 checker build 22 2010-07-20 18:21 checker 0 drwxr-xr-x 1 richrich 1322 2010-07-21 12:44 rich 0 drwxr-xr-x 1 rootroot36 2010-07-21 10:47 za-cb This would seem to indicate a non-zero exit status despite the fact that the snapshotting operation appears to have succeeded. This makes it impossible to programmatically check whether a snapshot was created successfully or not as I will need to explicitly discard the exit status from btrfsctl. I get the same results when built from git, except that it identifies itself as v0.19-16-g075587c. I would expect that btrfsctl would return zero exit status when it was capable of doing what it was asked and non-zero exit status only when it could not. --rich -- 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 -- 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: unable to replace defect raid1 device
Try to add replacement, rebalance, then remove missing C Anthony [mobile] On Jul 31, 2010, at 2:04 PM, Michael Kofler mich...@kofler.info wrote: on Ubuntu 10.10 alpha with btrfs 0.19 and a 2.6.35 (2.6.35-12-generic #17-Ubuntu SMP Mon Jul 26 18:48:06) I created a btrfs raid 1 system: # mkfs.btrfs -d raid1 -m raid1 /dev/sdb1 /dev/sdc1 Then I rebooted without disk 3 (/dev/sdc). I was able to mount the btrfs with mount -o degraded. However, I was not able to remove the defect device. # btrfs device delete /dev/sdc1 ERROR: error removing the device '/dev/sdc1' # dmesg | tail ... [ 110.524145] btrfs: allowing degraded mounts [ 439.104487] btrfs: unable to go below two devices on raid1 I was able to add a new device (again /dev/sdc1, but on another disk), but apparently it was not used as a raid1 device: # btrfs de add /dev/sdc1 /media/btrfs/ # btrfs fi sh Label: none uuid: dc691a5d-187e-4cb4-a94a-d12dabdffde4 Total devices 3 FS bytes used 3.76GB devid1 size 8.00GB used 5.35GB path /dev/sdb1 devid3 size 8.00GB used 0.00 path /dev/sdc1 *** Some devices missing Is there a way to replace a defect raid1 device as with mdadm? Or is this not yet implemented in btrfs? Best wishes, Michael Kofler -- 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 -- 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: quick question...
i'm not an expert, but ill do my best to answer. replies interspersed below. On Sun, Aug 8, 2010 at 8:57 PM, Evert Vorster evors...@gmail.com wrote: Hi there. Has anybody got a btrfs root filesystem that is running on a bare block device? Would lilo be able to boot an initramfs that is living on such a filesystem? i haven't [ever] used lilo, but AFIAK no bootloader, with the exception of maybe syslinux (extlinux), can boot from a btrfs device; you won't have to worry about the initramfs, because the loader won't even be able to find the kernel. you'll need a boot partition with a filesystem supported by the loader. What I intend to do is to erase all the partitions off my system, make a btrfs volume on /dev/sda, and then just use subvolumes in stead of partitions. Is this folly? not at all. this is what many of us would like to do, but we run into the bootloader issues above. Would having an initramfs be a boon or a bane in this endeavour? a non-issue, as the bootloader cannot even get the kernel (unless your booting the kernel/initramfs from a different device...) Would lilo writing to the mbr of a device that is claimed by btrfs break the file system? i don't think so, but i'm not sure. Do you need to have a partition table to have an MBR? i just read about this recently. IIRC, the partition table is within the 512 byte MBR; it's a 64 byte section starting at byte 446. so... no :-) 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: can't unmount
On Aug 12, 2010, at 10:58 AM, K. Richard Pixley r...@noir.com wrote: And should I be worried about what umount -l might be leaving behind? (eg, any unfreed kernel resources) Or is that a reasonable way to deal with this situation on an ongoing basis? --rich On 8/12/10 08:55 , K. Richard Pixley wrote: I'm running into a situation where I can't unmount a mounted snapshot. It shows busy even though neither lsof nor fuser show any open files. Umount -f doesn't work although umount -l does. Is there anything else I can do to debug this scenario or to clear the busy status myself? Or am I down to rebooting each time? This is on stock ubuntu-10.04, x86. --rich You are lazy unmounting, as I understand, you are essentially just hiding the fact that the mount was busy to userspace... The mount will remain active in the kernel until you resolve whatever was stopping umount in the first place; kernel will then silently unmount. Does this affect all of your mounted snapshots, or only a particular one? C Anthony [mobile] -- 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: Question of stability
On Sep 18, 2010, at 6:55 PM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: - Original Message - On Sat, Sep 18, 2010 at 11:37 PM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: Hi all I've been on this list for a year or so, and I have been following progress for some more. Are there any chances of btrfs stabilizing, as in terms of usability in production? If so, how far are we from this? Hi, I am using btrfs as my root filesystem on my Debian squeeze machine for a few month now and so far I haven't experienced any problems. It seems quite stable for me. I am not using raid functions, but am also very interested in the progress in raid5/6. I was more interested in large setups than a general install. Question remains, when is btrfs supposed to be stable, as in usable for large server setups? Stable is a pretty subjective term; many don't even think ext4 is stable. I've used it on my personal machine since .30-31-ish without problems, and on a server w/raid 1 for about a year (btrfs + lxc is niiice, for VMs) also free of problems. However, if you've been on the list you know that some do encounter seemingly catastrophic problems, though the list is helpful in recovering data. So, it's really going to depends on your workload and integrity needs. I remeber someone recently using it for continuous build servers successfully -- 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: Question of stability
On Sat, Sep 18, 2010 at 9:00 PM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: Stable is a pretty subjective term; many don't even think ext4 is stable. I've used it on my personal machine since .30-31-ish without problems, and on a server w/raid 1 for about a year (btrfs + lxc is niiice, for VMs) also free of problems. However, if you've been on the list you know that some do encounter seemingly catastrophic problems, though the list is helpful in recovering data. So, it's really going to depends on your workload and integrity needs. I remeber someone recently using it for continuous build servers successfully The term stable may be subjective at times, but for btrfs to be stable, it needs a working filesystem, with offline or online fsck abilities, and allowing for what's in the idea of btrfs, that is, checksumming everything, allowing snapshots and rollbacks et cetera. If btrfs is only stable as in ext4, well, why not just use ext4? The whole reason for btrfs to exist is to bring something new into the Linux world, and if those features aren't stable, then btrfs isn't. It's as simple as that. Would you buy a Subaru (or something) 4wd with a 2wd working? whoa, relax; that's a terrible analogy ;-) ) the term stability is _always_ subjective ) fsck has nothing to do with the filesystem itself, and does not contribute to it's operational stability ) checksums work fine ) snapshots work fine ) rollbacks are an implementation detail using snapshots; has nothing to do w/filesystem, afiak ) ehm, i suppose you would use btrfs over ext4 because you need it's features? beats me; you decide :-) ) have proper backup/failover options and it won't matter which you choose ) i'm sure that's not a reason ;-) ) btrfs has several pending/potential features/patches/branches floating around such as raid5/6, hot data awareness, etc. -- these unimplemented features (likely) do not detract from the stability of what's implemented now i apologize for the terseness, but i'm not sure what you're after exactly -- you said you have been on the list for a year, and thus should already have a pretty good idea of the current state, and what you can/cannot do? this (vague and _subjective_) question pops up from time to time, along with questions about raid5/6, etc., and they pretty much receive the same response i gave you: ) not everything possible/interesting is planned ) not everything planned is implemented ) some people run into big problems ) the majority likely does not ) use at your own risk ) many, including myself and the previous responder, are currently using it for a wide range of capacities, successfully, and collectively believe the minds responsible for btrfs must be rather competent folk, because for the most part... things are pretty quiet around here :-) 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: Question of stability
On Mon, Sep 20, 2010 at 10:12 AM, K. Richard Pixley r...@noir.com wrote: On 9/18/10 17:43 , C Anthony Risinger wrote: I remeber someone recently using it for continuous build servers successfully That's probably me and I wouldn't call the effort successful yet. There are at least several outstanding problems including the limit on the number of links to a file. More on all of these when I return from vacation next week. yes i think you're right; i actually was going to add that, but i accidentally hit 'send' on my mobile right after typing 'successfully' and never bothered to follow up with the last 2 or 3 sentences i had planned :-), meh. at any rate, while there is no doubt some issues (esp. with more aggressive/non-typical setups), i still think there are many who are using it successfully; at least this is the impression i get from my statistically irrelevant sampling of the various forums, lists, etc. i frequent. 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: Slow link/Capacity changed + Kernel OOPS... possible hardware issues, ideas?
On Thu, Oct 7, 2010 at 10:20 PM, Chris Ball c...@laptop.org wrote: Hi, can anyone point me in the right direction? it looks like maybe the SSD is failing to me (all the slow link and capacity changed to 0 stuff), but i really don't know. i knew there was a reason they were selling these things cheap on Newegg!!! Yes, the read errors are coming all the way up from the hardware; I don't think this is a btrfs problem. There's not much btrfs could do to help, except (over time) grow to handle I/O errors without BUG()ing out. hmm, i'll have to keep playing with it i guess. /dev/sda1 is a ext2 boot partition; i tar + ssh'ed that several times to my other machine without problems... i thought it would trip an issue if it really was hardware, but it didn't, even after 30+ times. i'll try to reinstall i guess, unless anyone has other input. i'll probably just have to ask ASUS to replace it, because i don't think i've even had it 6mo yet... :-O thanks, 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: Slow link/Capacity changed + Kernel OOPS... possible hardware issues, ideas?
On Fri, Oct 8, 2010 at 11:00 PM, Evert Vorster evors...@gmail.com wrote: Hi there... I'm not an expert. however, since you don't care about the data on the SSD anymore, reformat it, and fill it up, then verify what you have written. However, if the capacity has changed, would that not be enough reason to have ASUS replace it? yeah, i suppose i could :-) so i tried throwing ubuntu 10.10 on it (had archlinux previously), as i made a live USB disk so my fiancé could use it to write a paper today/tomorrow, and sure enough it worked, no problems whatsoever. been running several hours now after install... so i'm fairly convinced the SSD is still good enough, and i have no idea at this point what went wrong. oh well. 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: [PATCH] Btrfs: add support for mixed data+metadata block groups V3
On Thu, Oct 21, 2010 at 8:05 PM, Josef Bacik jo...@redhat.com wrote: On Thu, Oct 21, 2010 at 05:21:06PM -0500, Mitch Harder wrote: On Thu, Oct 21, 2010 at 5:09 PM, Diego Calleja dieg...@gmail.com wrote: On Jueves, 21 de Octubre de 2010 17:46:58 David Nicol escribió: Does this mixing constitute a forbidden change of on-disk format, and if not how not? It doesn't need a format change. The difference between a data and a metadata block group is just an allocation hint AFAIK. -- 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 Let me know if the problems with an un-patched kernel were un-expected. I can provide more information on the crash when booting an older kernel. Nope they are expected, it's not a disk format change, but older kernels won't deal with mixed block groups. When something like this goes mainline, is it used by default/automatically? I ask because I maintain a btrfs-based rollback initramfs hook [1], and am currently updating it for extlinux, enabling kernel-level system rollbacks via `btrfs set-default` + reboot (or maybe `kexec`)... rolling back to an old kernel will then blow up my machine (figuratively of course :-)? C Anthony [1] http://aur.archlinux.org/packages.php?ID=33376 -- 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] Btrfs: add support for mixed data+metadata block groups V3
On Thu, Oct 21, 2010 at 8:37 PM, Josef Bacik jo...@redhat.com wrote: On Thu, Oct 21, 2010 at 08:32:12PM -0500, C Anthony Risinger wrote: On Thu, Oct 21, 2010 at 8:05 PM, Josef Bacik jo...@redhat.com wrote: On Thu, Oct 21, 2010 at 05:21:06PM -0500, Mitch Harder wrote: On Thu, Oct 21, 2010 at 5:09 PM, Diego Calleja dieg...@gmail.com wrote: On Jueves, 21 de Octubre de 2010 17:46:58 David Nicol escribió: Does this mixing constitute a forbidden change of on-disk format, and if not how not? It doesn't need a format change. The difference between a data and a metadata block group is just an allocation hint AFAIK. -- 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 Let me know if the problems with an un-patched kernel were un-expected. I can provide more information on the crash when booting an older kernel. Nope they are expected, it's not a disk format change, but older kernels won't deal with mixed block groups. When something like this goes mainline, is it used by default/automatically? I ask because I maintain a btrfs-based rollback initramfs hook [1], and am currently updating it for extlinux, enabling kernel-level system rollbacks via `btrfs set-default` + reboot (or maybe `kexec`)... rolling back to an old kernel will then blow up my machine (figuratively of course :-)? The only way you get this feature is if you mkfs with the feature enabled, and is only meant for small filesystems (1 gig or smaller). Ah right :-), thanks 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: Determine if a given fs is a btrfs fs
On Mon, Oct 25, 2010 at 6:31 AM, Jérôme Poulin jeromepou...@gmail.com wrote:
On Sun, Oct 24, 2010 at 5:32 PM, Jérôme Poulin jeromepou...@gmail.com wrote:
...
p4 jerome # btrfs device scan /dev/dm-22
Scanning for Btrfs filesystems in '/dev/dm-22'
p4 jerome # echo $?
0
This is OK.
p4 jerome # btrfs device scan /dev/sda
Scanning for Btrfs filesystems in '/dev/sda'
ERROR: unable to scan the device '/dev/sda'
p4 jerome # echo $?
11
...
But isn't that error misleading, btrfs scan was succesfully able to
scan /dev/sda, but, it doesn't contain btrfs, right?
imo, the best way is:
# root must be btrfs else silent return
[ $(blkid -s TYPE -o value ${root}) = btrfs ] || return 0
at least that the way i do it in my initramfs hook; seems to be reliable.
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
Replacing the top-level root
On Mon, Oct 25, 2010 at 2:58 PM, Chris Mason chris.ma...@oracle.com wrote: Oh, and it shouldn't work on the root of the FS either ;) -chris This is not 100% related but... Will removing [replacing] the top-level root be something that can/will be supported? I've asked in the past about this regarding an initramfs hook i maintain implementing system rollbacks, but I never really got a solid answer. For example, right now extlinux support booting btrfs, but _only_ from the top-level root. if i just had a way to swap the top-level root with a different subvol, i could overcome several problems i have with users all at once: ) users install their system to the top-level root, which means it is no longer manageable by snapshot scripts [currently] ) if the top-level root could be swapped, extlinux could then boot my snapshot? (i'm probably wrong here) set-default is not enough; i'm looking for a way to gain control over the system state when the system has been installed into the top-level root. currently, i have no way to manipulate/move/change it, because the top-level is essentially immutable, or so it seems. thus it's not possible to support kernel rollbacks without manually syncing snapshot/boot to /boot. is there a solution to this that i'm missing? 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: 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: btrfs problems and fedora 14
On Mon, Nov 22, 2010 at 10:47 PM, Wenyi Liu qingshen...@gmail.com wrote: 2010/11/23, david grant d...@david-grant.com: I thought I would try btrfs on a new installation of f14. yes, I know its experimental but stable so it seemed to be a good time to try it. I am not sure if I have missed something out of all my searching but am I correct in thinking that currently: I. it is not possible to boot from a snapshot of the operating system and, in particular, the yum snapshots cannot be used for that purpose Is the Fedora grub support btrfs now? In this page http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs I got the following information: (deferred) a patch to grub1 -- on top of the already existing patch to support btrfs in grub1 -- to allow selecting between snapshots of the boot partition. all you need to do is add: subvol=name of the snapshot -- or -- subvolid=id of the snapshot to your kernel boot line (edit in grub on the fly)... however, if fedora is like archlinux in this respect (brief google search seems to agree), you will actually need to add this: rootflags=subvol=name of the snapshot where `rootflags` are the mount options passed to the initramfs/root device. also, you rally don't need grub, whatsoever[1]; in arch, we use an initramfs hook to perform system rollback by dynamically modifying the rootflags in accordance with the user's choice: http://aur.archlinux.org/packages/mkinitcpio-btrfs/mkinitcpio-btrfs/btrfs_hook perhaps someone in fedora can adapt that script... it's rather simple, and it's MUCH easier and safer than fiddling with grub legacy[1]. C Anthony [1] note however, that a proper grub2/extlinux solution is ideal to support kernel-level rollbacks. in the link above, everything is rolled back except the kernel (residing on /boot... non-btrfs). though, a kexec solution may be possible. -- 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
mounting arbitrary directories
i have read just recently and in the past that btrfs supports COW for _any_ file/directory (this is reflinks, yes?), and today i accidentally noticed that i can mount a directory as well (if it's in the top level volume at least). eg. if i have a regular directory (not a subvolume) in the top-level: /__boot i can mount it with: mount -o subvol=__boot /dev/sda /mnt is this supposed to be supported via the subvol mount option? though it sounds like i've answered my own question, i ask because playing around with this caused my kernel to oops for the first time in a long, long time (on .35 but just about to upgrade to .36 in about 10 min). i am working on an update to my initramfs hook that will utilize extlinux, and this property to provide seamless kernel level system rollbacks, and i want to make sure it's safe to do this. also, is there a way to target an arbitrary directory? does subvol support paths yet, or maybe via subvolid somehow? essentially i just want to mount a directory inside a snapshot at /boot, so when users upgrade there kernels, the images are visible to extlinux (which cannot yet peek inside or use subvolumes, so it has to be a regular directory in the top-level volume) any insight is much appreciated. 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: [RFC-PATCH] Re: mounting arbitrary directories
On Sun, Nov 28, 2010 at 4:07 AM, C Anthony Risinger anth...@extof.me wrote: On Nov 27, 2010, at 10:22 PM, Calvin Walton calvin.wal...@gmail.com wrote: On Sat, 2010-11-27 at 21:19 -0600, C Anthony Risinger wrote: eg. if i have a regular directory (not a subvolume) in the top- level: /__boot i can mount it with: mount -o subvol=__boot /dev/sda /mnt The 'subvol' option actually works using the same mechanism as a bind mount. The fact that it works using a directory is purely a coincidence - I would not expect it to be officially supported, and you shouldn't rely on it. Hrrrm... Well I thought I'd be clever and use this little trick one time to update my kernel... Anyways I oops out like 3 times in a row (last func was something.clone in each IIRC) and now I'm stuck with only my mobile since my server isn't set up yet and my SSD just failed on my netbook yesterday :-( So, if anyone can help me recover this partition long enough to grab a few things... I would be most grateful :-) I think I have everything critical, but I'd rather take another look :-) Right now I can't mount; mount is failing w/bad superblock. /me promises to never recklessly sabotage himself after being warned 6 hrs earlier any suggestions for me? i dd'ed the corrupt partition to an external disk because i need the machine back up and running, but if possible i'd like to get the image running again. i mounted it via loopback and as expected got the same errors: (will post the dmesg output next message -- left at home) open_ctree_fd failed wanted found instead the mount command itself fails with bad superblock or ... i have seen others withe similar crash reports and IIRC correctly were able to recover it (seems like something just didn't get updated right before it locked...) any ideas? 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: [GIT PULL][PATCH v2 0/6] btrfs: Add lzo compression support
On Wed, Nov 17, 2010 at 8:08 PM, Li Zefan l...@cn.fujitsu.com wrote: Hi Chris, Here's the updated patchset. As I still haven't got a kernel.org account, I have set up a git tree in another public git repository, and I'll use it for now. You can pull from: git://repo.or.cz/linux-btrfs-devel.git lzo-support Lzo is a much faster compression algorithm than gzib, so would allow more users to enable transparent compression, and some users can choose from compression ratio and compression speed. Usage: # mount -t btrfs -o compress[=zlib,lzo] dev /mnt or # mount -t btrfs -o compress-force[=zlib,lzo] dev /mnt -o compress without argument is still allowed for compatability. Compatibility: If we mount a filesystem with lzo compression, it will not be able be mounted in old kernels. One reason is, otherwise btrfs will directly dump compressed data, which sits in inline extent, to user. Performance: The test copied a linux source tarball (~400M) from an ext4 partition to the btrfs partition, and then extracted the tarball. (time in second) lzo zlib nocompress copy: 10.6 21.7 14.9 extract: 70.1 94.4 66.6 (data size in MB) lzo zlib nocompress copy: 185.87 108.69 394.49 extract: 193.80 132.36 381.21 Test: Mitch has tested the patchset, and provided some positive feedback. According to him, the patchset works as expected and nothing bad has he experienced. Other: The defrag ioctl is also updated, so one can choose lzo or zlib when turning on compression in defrag operation. Main change from v1: - Add incompat flag. - Fix build issue by selecting kernel lzo module. - Check compression type in defrag ioctl. Li Zefan (6): btrfs: Fix bugs in zlib workspace btrfs: Fix error handling in zlib btrfs: Allow to add new compression algorithm btrfs: Add lzo compression support btrfs: Allow to specify compress method when defrag btrfs: Extract duplicate decompress code fs/btrfs/Makefile | 2 +- fs/btrfs/btrfs_inode.h | 2 +- fs/btrfs/compression.c | 329 +- fs/btrfs/compression.h | 72 ++-- fs/btrfs/ctree.h | 11 +- fs/btrfs/extent_io.c | 5 +- fs/btrfs/extent_io.h | 17 ++- fs/btrfs/extent_map.c | 2 + fs/btrfs/extent_map.h | 3 +- fs/btrfs/file.c | 2 + fs/btrfs/inode.c | 82 ++ fs/btrfs/ioctl.c | 10 +- fs/btrfs/ioctl.h | 9 +- fs/btrfs/lzo.c | 409 +++ fs/btrfs/ordered-data.c | 18 ++- fs/btrfs/ordered-data.h | 8 +- fs/btrfs/super.c | 47 +- fs/btrfs/zlib.c | 361 +++-- 18 files changed, 1013 insertions(+), 376 deletions(-) is this in a branch somewhere? or for inclusion in .37/.38? this is a very attractive feature. what's the proper place (repo/branch) to see what is pending? 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: Default to read-only on snapshot creation and have a flag if snapshot should be writable (was: [PATCH 0/5] btrfs: Readonly snapshots)
On Nov 29, 2010, at 3:48 PM, Andrey Kuzmin andrey.v.kuz...@gmail.com wrote: I'm not sure why zfs came up, they don't own the term :). As to zfs/overhead topic, I doubt there's any difference between clone and writable shapshot (there should be none, of course, it's just two different names for the same concept). Regards, Andrey On Tue, Nov 30, 2010 at 12:43 AM, Mike Fedyk mfe...@mikefedyk.com wrote: On Mon, Nov 29, 2010 at 1:31 PM, Andrey Kuzmin andrey.v.kuz...@gmail.com wrote: This may sound excessive as any new concept introduction that late in development, but readonly/writable snapshots could be further differentiated by naming the latter clones. This way end-user would naturally perceive snapsot as read-only PIT fs image, while clone would naturally refer to (writable) head fork. I'm not sure we want to take all of the terminology that zfs uses as it may also bring the percieved drawbacks as well. Isn't there some additional overhead for a zfs clone compared to a snapshot? I'm not very familiar with zfs so that's why I ask. -- 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 I don't like the idea of readonly by default, or further changes to terminology, for several reasons: ) readonly by default offers no real enhancement whatsoever other than breaking _anything_ that's written right now ) btrfs readonly is not even really readonly; as superuser could simply flip a flag to enable writes, readonly merely prevents accidental writes or misbehaving apps... ie. protecting you from yourself ) backups are the simple/obvious use case; I personally use btrfs heavily for LXC containers, in which case nearly every single snapshot is intended to be writable -- usually cloning a template into a new domain ) I also use an initramfs hook to provide system rollbacks, also writable; the hook also provides multiple versions of the branch... all writable ) adding new terms is not a good idea imo; I've already spewed out many sentences explaining the difference between subvolumes and snapshots, ie. that there is none... adding another term only adds to this problem; they each describe the same thing, but differentiate based on origin or current state, neither of which actually describe what it _is_-- a new named pointer to a tree, like a git branch -- a subvolume. I think a better solution/compromise would be to leave snapshots writeable by default, since that's more true to what's happening internally anyway, but maybe introduce a mount option controlling the default action for that mount point. C Anthony [mobile] -- 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: [GIT PULL][PATCH v2 0/6] btrfs: Add lzo compression support
On Mon, Nov 29, 2010 at 7:00 PM, Li Zefan l...@cn.fujitsu.com wrote: C Anthony Risinger wrote: On Wed, Nov 17, 2010 at 8:08 PM, Li Zefan l...@cn.fujitsu.com wrote: You can pull from: git://repo.or.cz/linux-btrfs-devel.git lzo-support Lzo is a much faster compression algorithm than gzib, so would allow more users to enable transparent compression, and some users can choose from compression ratio and compression speed. is this in a branch somewhere? or for inclusion in .37/.38? this is a very attractive feature. what's the proper place (repo/branch) to see what is pending? As a new feature, it's too late for .37. Hope to see it merged in .38 merge window. :-( yeah i thought it was already too late for .37, but i'd love to see this for .38... should add even more kick to my eee s101 netbook. Chris' btrfs-unstable git tree is the official place to see what is pending, but just he hasn't picked up those patches, so for now it only sits in my own tree. i knew about Chris' tree, i probably should have been more clear; instead of pending i should have said awaiting review, ie. is there a repo Chris or someone else keeps with all the potential patches (such as this, or the recent readonly ones, etc.)? i keep a pretty good eye on the list, but i thought maybe someone already had a nice central point to see these up and coming patches that aren't necessarily pending for mainline yet. thanks Li, 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: What to do about subvolumes?
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 this is too tricky. We want this because you can only take snapshots of subvolumes, and so it is important that users be able to create their own discrete snapshottable targets. 2) Users need to be able to snapshot their subvolumes. This is basically the same as #1, but it bears repeating. could it be possible to convert a directory into a volume? or at least base a snapshot off it? 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: What to do about subvolumes?
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) 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 subvolumes, and so it is important that users be able to create their own discrete snapshottable targets. 2) Users need to be able to snapshot their subvolumes. This is basically the same as #1, but it bears repeating. could it be possible to convert a directory into a volume? or at least base a snapshot off it? I'm afraid this turns into the same complexity as creating a new volume and copying all the files/dirs in by hand. ok; if i create an empty volume, and use cp --reflink, it would have the desired affect though, right? 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: What to do about 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 here. There are really 2 things here 1) Limiting the size of subvolumes. This is really easy for us, just create a subvolume and at creation time set a maximum size it can grow to and not let it go farther than that. Nice, simple and straightforward. 2) Normal quotas, via the quota tools. This just comes down to how do we want to charge users, do we want to do it per subvolume, or per filesystem. My vote is per filesystem. Obviously this will make it tricky with snapshots, but I think if we're just charging the diff's between the original volume and the snapshot to the user then that will be the easiest for people to understand, rather than making a snapshot all of a sudden count the users currently used quota * 2. This is going to be tricky to get the semantics right, I suspect. Say you've created a subvolume, A, containing 10G of Useful Stuff (say, a base image for VMs). This counts 10G against your quota. Now, I come along and snapshot that subvolume (as a writable subvolume) -- call it B. This is essentially free for me, because I've got a COW copy of your subvolume (and the original counts against your quota). If I now modify a file in subvolume B, the full modified section goes onto my quota. This is all well and good. But what happens if you delete your subvolume, A? Suddenly, I get lumbered with 10G of extra files. Worse, what happens if someone else had made a snapshot of A, too? Who gets the 10G added to their quota, me or them? What if I'd filled up my quota? Would that stop you from deleting your copy, because my copy can't be charged against my quota? Would I just end up unexpectedly 10G over quota? This is a whole gigantic can of worms, as far as I can see, and I don't think it's going to be possible to implement quotas, even on a filesystem level, until there's some good and functional model for dealing with all the implications of COW copies. :( i'd expect that as a separate user, you should both be whacked 10G. imo, the whole benefit of transparent COW is to the administrators advantage, thus i would even think the _uncompressed_ volume size would go against quota (which could possibly be artificially inflated to account for the space saving of compression). users just need a nice steadily predictable number to monitor. thought maybe these users could be grouped, such that the COW'ed portions of the files they share are balanced across each users quota, but this would have to be a soprt of opt in thing else you get the wild fluctuations because of other user's actions. additionally, some users could be marked as system, where COW'ing their subvol results in 0 quota -- you only pay for what you change -- but if the system subvol gets removed, then you pay for it all. in this way you would have to keep reusing system subvols to get any advantage as a regular user. i dont know the existing systems though so i dont know what it would take to do such balancing. 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: What to do about subvolumes?
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 capability. In fact it is possible to make a snapshot of the root of the filesystem and to mount it in a subsequent reboot. But is very complicated to manage the pivoting of a snapshot of a root filesystem, because I cannot delete the old root due to the fact that the new root is placed in the old root. A possible solution is not to put the root of the filesystem (where are placed /usr, /etc) in the root of the btrfs filesystem; but it should be accepted from the beginning the idea that the root of a filesystem should be placed in a subvolume which int turn is placed in the root of a btrfs filesystem... I am open to other opinions. Agreed, one of the things that Chris and I have discussed is the possiblity of just having dangling roots, since really the directories are just an easy way to get to the subvolumes. This would let you delete the original volume and use the snapshot from then on out. Something to do in the future for sure. i would really like to see a solution to this particular issue. i may be missing something, but the dangling subvol roots doesn't seem to address the management of the root volume itself. for example... most people will install their whole system into the real root (id=5), but this renders the system unmanageable, because there is no way to ever empty it without manually issuing an `rm -rf`. i'm having a really hard time controlling this with the initramfs hook i provide for archlinux users. the hook requires a specific structure underneath what the user perceives as /, but i can only accomplish this for new installs -- for existing installs i can setup the proper subroot structure, and snapshot their current root... but i cannot remove the stagnant files in the real root (id=5) that well never, ever be accessed again. ... or does dangling roots address this? 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: What to do about subvolumes?
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 the subvolumes. One of the most beautiful feature of btrfs is the snapshot capability. In fact it is possible to make a snapshot of the root of the filesystem and to mount it in a subsequent reboot. But is very complicated to manage the pivoting of a snapshot of a root filesystem, because I cannot delete the old root due to the fact that the new root is placed in the old root. A possible solution is not to put the root of the filesystem (where are placed /usr, /etc) in the root of the btrfs filesystem; but it should be accepted from the beginning the idea that the root of a filesystem should be placed in a subvolume which int turn is placed in the root of a btrfs filesystem... I am open to other opinions. Agreed, one of the things that Chris and I have discussed is the possiblity of just having dangling roots, since really the directories are just an easy way to get to the subvolumes. This would let you delete the original volume and use the snapshot from then on out. Something to do in the future for sure. i would really like to see a solution to this particular issue. i may be missing something, but the dangling subvol roots doesn't seem to address the management of the root volume itself. for example... most people will install their whole system into the real root (id=5), but this renders the system unmanageable, because there is no way to ever empty it without manually issuing an `rm -rf`. i'm having a really hard time controlling this with the initramfs hook i provide for archlinux users. the hook requires a specific structure underneath what the user perceives as /, but i can only accomplish this for new installs -- for existing installs i can setup the proper subroot structure, and snapshot their current root... but i cannot remove the stagnant files in the real root (id=5) that well never, ever be accessed again. ... or does dangling roots address this? 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 id=0, or remark 0 as the default. effectively, users would be unknowingly be installing into a subvolume, rather then the top-level root (apologies if my terminology is incorrect). 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: disk space caching generation missmatch
On Thu, Dec 2, 2010 at 2:34 PM, Josef Bacik jo...@redhat.com wrote:
+ if (!ret) {
+ spin_lock(block_gruop-lock);
+ block_group-disk_cache_state = BTRFS_DC_SETUP;
+ spin_unlock(block_group-lock);
+ }
misspelling:
block_gruop - block_group
just noticed this glancing thru...
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: disk space caching generation missmatch
Did you fix that typo I posted? C Anthony [mobile] On Dec 2, 2010, at 6:05 PM, Johannes Hirte johannes.hi...@fem.tu-ilmenau.de wrote: On Thursday 02 December 2010 21:34:10 Josef Bacik wrote: On Wed, Dec 01, 2010 at 10:40:29PM +0100, Johannes Hirte wrote: On Wednesday 01 December 2010 22:22:45 Johannes Hirte wrote: On Wednesday 01 December 2010 21:03:13 Josef Bacik wrote: On Wed, Dec 01, 2010 at 08:56:14PM +0100, Johannes Hirte wrote: On Wednesday 01 December 2010 18:40:18 Josef Bacik wrote: On Wed, Dec 01, 2010 at 05:46:14PM +0100, Johannes Hirte wrote: After enabling disk space caching I've observed several log entries like this: btrfs: free space inode generation (0) did not match free space cache generation (169594) for block group 15464398848 I'm not sure, but it seems this happens on every reboot. Is this something to worry about? So that usually means 1 of a couple of things 1) You didn't have space for us to save the free space cache 2) When trying to write out the cache we hit one of those cases where we would deadlock so we couldn't write the cache out It's nothing to worry about, it's doing what it is supposed to. However I'd like to know why we're not able to write out the cache. Are you running close to full? Thanks, Josef I think there should be enough free space: Ok it doesn't look like theres an actual problem, we're just being sub-optimal. Take out the other patch and apply this one, boot into that kernel and then reboot and then give me the dmesg. Here it comes: Initializing cgroup subsys cpuset Linux version 2.6.37-rc4-space-cache-dbg-00022-g620731b-dirty (r...@netbook) (gcc version 4.5.1 (Gentoo 4.5.1-r1 p1.3, pie-0.4.5) ) #126 SMP PREEMPT Fri Dec 3 00:40:04 CET 2010 Atom PSE erratum detected, BIOS microcode update recommended BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000dc000 - 000e4000 (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 7f6d (usable) BIOS-e820: 7f6d - 7f6e2000 (ACPI data) BIOS-e820: 7f6e2000 - 7f6e3000 (ACPI NVS) BIOS-e820: 7f6e3000 - 8000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed0 - fed00400 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed9 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff00 - 0001 (reserved) NX (Execute Disable) protection: active DMI present. DMI: M912/M912, BIOS R02 05/04/2009 e820 update range: - 0001 (usable) == (reserved) e820 remove range: 000a - 0010 (usable) last_pfn = 0x7f6d0 max_arch_pfn = 0x100 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-B uncachable C-C write-protect D-D uncachable E-F write-protect MTRR variable ranges enabled: 0 base 0 mask 08000 write-back 1 base 07F70 mask 0FFF0 uncachable 2 base 07F80 mask 0FF80 uncachable 3 disabled 4 disabled 5 disabled 6 disabled 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 Scanning 0 areas for low memory corruption initial memory mapped : 0 - 01a0 init_memory_mapping: -37bfe000 00 - 0037bfe000 page 4k kernel direct mapping tables up to 37bfe000 @ 183f000-1a0 ACPI: RSDP 000f7e40 00024 (v02 GBT ) ACPI: XSDT 7f6dc705 00084 (v01 GBTGBTUACPI 0604 LTP ) ACPI: FACP 7f6e1bd2 000F4 (v03 INTEL CALISTGA 0604 ALAN 0001) ACPI: DSDT 7f6dd907 04257 (v01 INTEL CALISTGA 0604 INTL 20050624) ACPI: FACS 7f6e2fc0 00040 ACPI: APIC 7f6e1cc6 00068 (v01 INTEL CALISTGA 0604 LOHR 005A) ACPI: HPET 7f6e1d2e 00038 (v01 INTEL CALISTGA 0604 LOHR 005A) ACPI: MCFG 7f6e1d66 0003C (v01 INTEL CALISTGA 0604 LOHR 005A) ACPI: SLIC 7f6e1da2 00176 (v01 GBTGBTUACPI 0604 TBD 0001) ACPI: TCPA 7f6e1f18 00032 (v01 PTLTD CALISTGA 0604 PTL 0001) ACPI: TMOR 7f6e1f4a 00026 (v01 PTLTD 0604 PTL 0003) ACPI: APIC 7f6e1f70 00068 (v01 PTLTD ? APIC 0604 LTP ) ACPI: BOOT 7f6e1fd8 00028 (v01 PTLTD $SBFTBL$ 0604 LTP 0001) ACPI: SSDT 7f6dcd25 0025F (v01 PmRef Cpu0Tst 3000 INTL 20050624) ACPI: SSDT 7f6dcc7f 000A6 (v01 PmRef Cpu1Tst 3000 INTL 20050624) ACPI: SSDT 7f6dc789 004F6 (v02 PmRefCpuPm 3000 INTL 20050624) ACPI: BIOS bug: multiple APIC/MADT found, using 0 ACPI: If acpi_apic_instance=2 works better, notify linux-a...@vger.kernel.org ACPI: Local APIC address 0xfee0
Re: [RFC-PATCH] Re: mounting arbitrary directories
On Mon, Nov 29, 2010 at 11:42 AM, C Anthony Risinger anth...@extof.me wrote: On Sun, Nov 28, 2010 at 4:07 AM, C Anthony Risinger anth...@extof.me wrote: On Nov 27, 2010, at 10:22 PM, Calvin Walton calvin.wal...@gmail.com wrote: On Sat, 2010-11-27 at 21:19 -0600, C Anthony Risinger wrote: eg. if i have a regular directory (not a subvolume) in the top- level: /__boot i can mount it with: mount -o subvol=__boot /dev/sda /mnt The 'subvol' option actually works using the same mechanism as a bind mount. The fact that it works using a directory is purely a coincidence - I would not expect it to be officially supported, and you shouldn't rely on it. Hrrrm... Well I thought I'd be clever and use this little trick one time to update my kernel... Anyways I oops out like 3 times in a row (last func was something.clone in each IIRC) and now I'm stuck with only my mobile since my server isn't set up yet and my SSD just failed on my netbook yesterday :-( So, if anyone can help me recover this partition long enough to grab a few things... I would be most grateful :-) I think I have everything critical, but I'd rather take another look :-) Right now I can't mount; mount is failing w/bad superblock. /me promises to never recklessly sabotage himself after being warned 6 hrs earlier any suggestions for me? i dd'ed the corrupt partition to an external disk because i need the machine back up and running, but if possible i'd like to get the image running again. i mounted it via loopback and as expected got the same errors: (will post the dmesg output next message -- left at home) open_ctree_fd failed wanted found instead the mount command itself fails with bad superblock or ... i have seen others withe similar crash reports and IIRC correctly were able to recover it (seems like something just didn't get updated right before it locked...) any ideas? dmesg output was: -- device label root devid 1 transid 61235 /dev/loop0 parent transid verify failed on 11335634944 wanted 61235 found 61237 parent transid verify failed on 11335634944 wanted 61235 found 61237 parent transid verify failed on 11335634944 wanted 61235 found 61237 btrfs: open_ctree failed -- i tried btrfsck as suggested in the recent thread: -- # sudo losetup /dev/loop0 /mnt/btrfs.img # sudo btrfsck -s 1 /dev/loop0 using SB copy 1, bytenr 67108864 parent transid verify failed on 11335634944 wanted 61235 found 61237 parent transid verify failed on 11335634944 wanted 61235 found 61237 parent transid verify failed on 11335634944 wanted 61235 found 61237 btrfsck: disk-io.c:739: open_ctree_fd: Assertion `!(!tree_root-node)' failed. # sudo btrfsck -s 2 /dev/loop0 using SB copy 2, bytenr 274877906944 No valid Btrfs found on /dev/loop0 -- s... does this mean i'm totally boned for ever mounting this image again? or should i keep it around for later? or anything else i can try/do? 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: crash when mounting subvolume in a subdirectory
On Mon, Dec 6, 2010 at 7:40 PM, Li Zefan l...@cn.fujitsu.com wrote: Michael Niederle wrote: Hi! I'm not sure whether this *should* be possible, but I think it *shouldn't* crash: It's currently not allowed to mount a subvolume which is not created in the root directory of the default subvolume, so you should have failed to mount, but you hit a bug.. I've fixed it, and will send out the patch in minutes. i did the same thing, except for a slightly different reason and slightly more accidentally on purpose: http://www.spinics.net/lists/linux-btrfs/msg07190.html but, i ended up with a corrupted FS (that i still have a dump of, happily waiting for a way to mount it... *hint* :-) so if your are still up and running then luck is on your side, and don't do it again ;-) 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: severe hardlink bug
On Sun, Jul 29, 2012 at 2:02 PM, Konstantin Dmitriev
ksee.zelga...@gmail.com wrote:
Dipl.-Ing. Michael Niederle mniederle at gmx.at writes:
I reinstalled over 700 packages - plt-scheme beeing the only one failing due
to
the btrfs link restriction.
I have hit the same issue - tried to run BackupPC with a pool on btrfs
filesystem. After some time the error of too many links (31) appeared to me.
Now I'm forced to migrate to some other filesystem...
btrfs only fails when you have hundreds of hardlinks to the same file
in the *same* directory ... certainly not a standard use case.
use snapshots to your advantage:
- snap source
- rsync --inplace source to target (with some other opts that have
been discussed on list)
- snap target
- {rinse-and-repeat-in-24-hrs}
--
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: severe hardlink bug
On Mon, Jul 30, 2012 at 4:36 AM, Arnd Hannemann a...@arndnet.de wrote: Am 29.07.2012 21:13, schrieb C Anthony Risinger: On Sun, Jul 29, 2012 at 2:02 PM, Konstantin Dmitriev ksee.zelga...@gmail.com wrote: Dipl.-Ing. Michael Niederle mniederle at gmx.at writes: I reinstalled over 700 packages - plt-scheme beeing the only one failing due to the btrfs link restriction. I have hit the same issue - tried to run BackupPC with a pool on btrfs filesystem. After some time the error of too many links (31) appeared to me. Now I'm forced to migrate to some other filesystem... btrfs only fails when you have hundreds of hardlinks to the same file in the *same* directory ... certainly not a standard use case. Actually, hundreds of hardlinks is certainly over optimistic. In my testing 15 links in the same directory were enough to get the Too many links error. It depends on the length of the file name of the hardlinks. Yes, per the linked patch it states 4k as the limit ... I thought I recalled a limit of 256 but it seems I may have been mistaken. The purpose of my initial response was to suggest an alternative strategy -- one complementing btrfs's strengths -- a simple rsync + snapshot is much more effective than BackupPC IMO ... but then again, I'm bias, because I generally think BackupPC is junk. -- 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: How to get Btrfs on 2nd partition of USB HDD to automount as read/write
On Sun, Aug 19, 2012 at 2:51 PM, dg1727 dg1...@hushmail.com wrote: permissions of the directories in /dev are drwx-- for the NTFS and dr-xr-xr-x for the Btrfs. How can the OS be set up so that the Btrfs will automount read/write? try: chmod u+w /path/to/btrfs/mount ... for whatever reason mkfs.btrfs created new subvolumes (but not snapshots!) with 555 perms, which essentially says writable to nobody at all ... IIRC, this was changed within the last year or so. -- 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: Feeback on RAID1 feature of Btrfs
On Tue, Dec 18, 2012 at 6:13 AM, Hugo Mills h...@carfax.org.uk wrote:
On Tue, Dec 18, 2012 at 01:20:20PM +0200, Brendan Hide wrote:
On 2012/12/17 06:23 PM, Hugo Mills wrote:
On Mon, Dec 17, 2012 at 04:51:33PM +0100, Sebastien Luttringer wrote:
Hello,
snip
I get the feeling that RAID1 only allow one disk removing. Which is more
a RAID5 feature.
The RAID-1 support in btrfs makes exactly two copies of each item
of data, so you can lose at most one disk from the array safely. Lose
any more, and you're likely to have lost data, as you've found out.
I'm afraid Btrfs raid1 will not be working before the end of the world.
It does work (as you demonstrated with the first disk being
removed) -- but just not as you thought it should. Now, you can argue
that RAID-1 isn't a good name to use here, but there's no good name
in RAID terminology to describe what we actually have here.
Technically, btrfs's RAID1 implementation is much closer to RAID1E
than traditional RAID1. See
http://en.wikipedia.org/wiki/Non-standard_RAID_levels#RAID_1E or
http://pic.dhe.ibm.com/infocenter/director/v5r2/index.jsp?topic=/serveraid_9.00/fqy0_craid1e.html
Perhaps a new name, as with ZFS, might be appropriate. RAID-Z and
RAID-Z2, for example, could not adequately be described by any
existing RAID terminology and, technically, RAID-Z still isn't a
RAID in the classical sense.
Yeah, we did have a naming scheme proposed, with combinations of
nCmSpP, where n is the number of copies held, m the number of stripes,
and p the number of parity stripes. So btrfs RAID-1 is 2C, RAID-5 on 5
disks would be 4S1P, and RAID-10 on 4 disks would be 2C2S.
...yes. something like this is not only reflects reality better,, and
actually transfers information in consistent way (vs RAID-XYZ...
meaningless ENUM!) you could maybe do something like:
2C2S : -1S : 0
...or similar, showing:
{normal}
{OFFSET max degraded [rel boundary]}
{OFFSET current}
... which instantly makes the useful boundaries known, along with the
active panic level i should be experiencing :)
I'd prefer
to see that than some non-standard RAID-18KTHXBYE formulation.
^^^ this. the term RAID conjures expectations that run afoul of
btrfs's reality and should thus simply be avoided altogether
IMO, unless you wish/must explicitly correlate some similarity X,
there is no need to even mention the work RAID, because it carries no
information.
--
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: Btrfs partition lost after RAID1 mirror disk failure?
On Tue, Jan 3, 2012 at 8:44 AM, Dan Garton dan.gar...@gmail.com wrote: [...] 1327 btrfs-vol -a 1328 btrfs-vol -a /nuvat 1329 btrfs-vol -a asdasd /nuvat 1330 btrfs-vol -a missing /nuvat 1331 btrfs-vol -a /dev/sdc /nuvat 1332 btrfs-vol -a /dev/sdb /nuvat 1334 btrfs-vol -a missing /nuvat [...] these look destructive to me ... adding the wrong devices and the existing devices back to the current array? IIRC you should have `-r missing`, but in general, do not use the btrfsctl utility at all -- it won't have as much visibility/exception-handling/recovery as the `btrfs` utility. at what point did your FS become inaccessible? your command history suggest it was working until shortly after these commands ... :-( -- 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: Btrfs partition lost after RAID1 mirror disk failure?
On Wed, Jan 4, 2012 at 2:30 PM, Dan Garton dan.gar...@gmail.com wrote: Assuming that this is the case, do I stand a chance of retrieving that volume and accessing that data again? Or does destructive imply total loss? (In which case, I'll cut my losses) unfortunately i really don't know enough to advise ... i did similar actions a long time ago while experimenting for an initcpio-based rollback utility, but in my case the FS was a dummy/loopback, so i just burned it. my only suggestion would be to try Josef's readonly recovery/slurp utility and maybe you can pull some data off, since my completely uninformed guess is the structures are 99% intact, but your UUIDs no longer match, or internal top-level pointers to wrong locations, etc etc. perhaps someone more familiar with actual internals can be of more help -- good luck. -- 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: Fractal Tree Indexing over B-Trees?
On Wed, Mar 28, 2012 at 9:25 AM, Danny Piccirillo danny.picciri...@member.fsf.org wrote: The case has been made on Phoronix for F-Trees: They makes use hard drive speeds, not (relatively slow) access times; beat SSD's; and scale perfectly across multiple cores with hundreds of millions of entries. http://en.wikipedia.org/wiki/TokuDB#Fractal_tree_indexes How TokuDB Fractal Tree Databases Work Via: http://www.phoronix.com/scan.php?page=news_itempx=MTA3NjM Time for someone to get started on ftrfs? Or can it be implemented in Btrfs? https://bugzilla.kernel.org/show_bug.cgi?id=43004 whoa, very cool stuff. fractals are awesome, cool to see them in use. ... 2010/11, surprised i never heard of it before now. thanks for the reference/links at the very least! aside: i once described fractals to my grandmother (100% devout catholic) as related to my own understanding of the universe -- specifically, i pointed out how their often simple mathematical identity fragments into an infinitely self-similar pattern of seemingly unbounded complexity -- she told me i was describing god ... and, well, we agreed :-) -- 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: Moving top level to a subvolume
On Fri, Jun 8, 2012 at 2:40 PM, Arne Jansen sensi...@gmx.net wrote: On 06/08/2012 09:24 PM, Matthew Hawn wrote: I just converted my root filesystem to btrfs with btrfs-convert. However, since I am running Ubuntu, I would like to have the same subvolume structure as a default install,. How do I move the top-level subvolume (where all my files currently are) to another subvolume? Just snapshot the root subvol and continue working in the snapshot. ... yeah but that solution totally sucks when you: a) have a lot of data b) need to do this via script c) ??? ... because in a), data will *copied* the slow way, and in b) you leave a bunch of junk laying around in the old root that will rot unless you `rm -rf` it ... and idk about you, but issuing what is very near to that command on someone else's machine -- via script -- makes me REALLY uneasy ;-) i have asked this exact question at least 4 times specifically, and referenced it probably 8-10, in the last 3 years or more. i needed it then. i still need it now. but since i never got an answer up/down or around, i gave up and told people to `rm -rf`themselves ... http://markmail.org/message/7hj5ioqrztkeerqv ... that's from May of 2010, but i don't think it's the first. so, would it possible to implement this, or could someone kindly (and briefly!) explain why it cannot be done? 1. people install stuff to the top-level 2. top-level is unmanageable 3. problem in my case i wrote an initramfs hook that implemented rollback functionality, but there was not way for me to cleanly -- and safely -- rotate the user's setup to one that DOES NOT have user items in the top-level volume. -- 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: Moving top level to a subvolume
On Wed, Jun 13, 2012 at 2:21 AM, Arne Jansen sensi...@gmx.net wrote:
On 13.06.2012 09:04, C Anthony Risinger wrote:
a) have a lot of data
b) need to do this via script
c) ???
... because in a), data will *copied* the slow way, and in b) you
leave a bunch of junk laying around in the old root that will rot
unless you `rm -rf` it ... [...]
What I don't understand is why you think data will be copied.
at one point i tried to create a new subvol and `mv` files there, and
it took quite some time to complete
(cross-link-device-what-have-you?), but maybe things changed ... will
try it out.
[...]
so, would it possible to implement this, or could someone kindly (and
briefly!) explain why it cannot be done?
The default subvol ('/') has the special number 5 and is expected to
always be around. All other subvols get numbers starting with 256.
Creating a new 5 and internally renumbering the old 5 isn't easy, because
each tree block has an owner recorded in it. Also, all backreferences
have the root number in them. If you have to touch each tree block, you
can as well choose the snapshot/rm -rf approach.
ok this makes sense thanks, the last sentence especially ... top-level
volume is different. it's identical to other subvols in 99% of ways
save one-gotcha-little-1%. couldn't we shield ourselves a little
better?
1. people install stuff to the top-level
2. top-level is unmanageable
3. problem
[...]
Can't instead add code to the installer that warns a user if he wants
to install into the default subvol?
Just some random ideas...
i would like to see #5 cut off from natural access: accessible by an
_explicit_ manual mount only, cannot be made default, and cannot be
removed. maybe btrfs manages a proxy/facade subvol, say, #10, settable
by `--flag-origin` or `{insert-here}` option -- a symlink to subvol?
if, at absolutely any time or whatever reason, #10 pointer should not
exist, immediately snapshot #5 and update.
#5 - #10 - #256+ ?
... this might allow the root to be replaced. default is set to #10
proxy volume when FS is initialized.
[...]
Or you could hack mkfs.btrfs to always create an additional subvol.
Even making / readonly except for creating mountpoint could be possible.
^ yeah, this sounds like exactly what i'm thinking, differing
mainly on who does the work... i just want a guaranteed way of
replacing the logical root, at #10. the physical root at #5 it's
more-or-less indestructible and off limits, and never available except
as a template.
... i am new to postgresql, but their template0/template1 feels
related to solving problems like this.
--
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
