Re: btrfs send does not work from readonly device
The snapshots underneath are set read only anyway in my case, since the they landed there by btrfs receive or I am thinking wrong here? Duncan, do you remember the bug number? Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs send does not work from readonly device
On Thu, 25 Sep 2014 21:39:41 +0200 G EO 1g2e...@gmail.com wrote: The snapshots underneath are set read only anyway in my case, since the they landed there by btrfs receive or I am thinking wrong here? Duncan, do you remember the bug number? I don't. I remember seeing the discussion on the list. Without googling my local list archive it seems to me it might have been in one of Marc Merlin's threads. -- Duncan - No HTML messages please, as they are filtered as spam. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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 send does not work from readonly device
GEO posted on Tue, 23 Sep 2014 14:58:06 +0200 as excerpted: Is that supposed to be that way? Why is readonly not enough to import data using btrfs send? This is a known issue. The subvolume itself needs to be set read-only, and of course that can't be done when the whole filesystem is set read- only. But a read-only filesystem should be sufficient, provided it can be forced to remain read-only thru the entire send. I think that's the worry, that someone will switch their system from ro to rw in the middle of a send, thus screwing it up. But they're aware of the problem and should eventually have a fix. But I'm not sure how long as there's other work going on too, of course. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs send does not work from readonly device
Let's say we have a snapshot called snapshot on our device /dev/sdb. Now we boot a qemu machine and attatch the disk read only (since we do not want to put our data at risk in the vm, and read only should be enough to get our snapshot data). I used qemu-system-x86_64 -drive -file=/dev/sdb,if=scsi,readonly -hda path_to_guest_operating_system When we are in the qemu instance (suppose our device /dev/sdb is mounted on /mnt/import), we want to import our data now using btrfs send/receive: btrfs send /mnt/import/snapshot | btrfs receive / we get the following problems in syslog due to the fact that our device is read only: delayed_refs has NO entry BTRFS warning (device sdb): btrfs_update_root:151: Aborting unsused transaction(No space left) BTRFS warning (device sdb): Skipping commit of aborted transaction. BTRFS warning (device sdb): cleanup_transaction:1547: Aborting unused transaction (No space left) Apart from the snapshot folder being created in / nothing happens, the process simply hangs forever, with no actual data getting imported. Is that supposed to be that way? Why is readonly not enough to import data using btrfs send? -- 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
