Re: ntfs -> qemu -> raw-image -> btrfs -> iscsi

2018-06-15 Thread ein
On 06/15/2018 08:10 PM, Austin S. Hemmelgarn wrote:
> On 2018-06-15 13:40, Chris Murphy wrote:
>> On Fri, Jun 15, 2018 at 5:33 AM, ein  wrote:
>>> Hello group,
>>>
>>> does anyone have had any luck with hosting qemu kvm images resided on BTRFS 
>>> filesystem while serving
>>> the volume via iSCSI?
>>>
>>> I encouraged some unidentified problem and I am able to replicate it. 
>>> Basically the NTFS filesystem
>>> inside RAW image gets corrupted every time when Windows guest boots. What 
>>> is weired is that changing
>>> filesystem for ext4 or xfs solves the issue.
>>>
>>> The problem replication looks as follows:
>>> 1) run chkdsk on the guest to make sure the filesystem structure is in good 
>>> shape,
>>> 2) shut down the VM via libvirtd,
>>> 3) rsync changes between source and backup image,
>>> 4) generate SHA1 for backup and original and compare it,
>>> 5) try to run guest on the backup image, I was able to boot windows once 
>>> for ten times, every time
>>> after reboot NTFS' chkdsk finds problems with filesystem and the VM is 
>>> unable to boot again.
>>>
>>> What am I missing?
>>>
>>> VM disk config:
>>>
>>>  
>>>    
>>
>>
>>
>> cache=none uses O_DIRECT, and that's the source of the issue with VM
>> images on Btrfs. Details are in the list archive.
>>
>> I'm not really sure what you want to use with Windows in this
>> particular case, probably not cache=unsafe though. I'd say give
>> writethrough a shot and see how it affects performance and fixes this
>> problem.
>>
> cache=writethrough is probably going to be the best option, unless you want 
> to switch to
> cache=writeback and disable write caching in Windows (which from what I hear 
> can actually give
> better performance than using cache=none).

Thank you to each and everyone of you, I'll give it a shot. Performance is not 
a problem, recovery
purposes only, I'd like to run the VM once to dump some configuration data.
--
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: ntfs -> qemu -> raw-image -> btrfs -> iscsi

2018-06-15 Thread Austin S. Hemmelgarn

On 2018-06-15 13:40, Chris Murphy wrote:

On Fri, Jun 15, 2018 at 5:33 AM, ein  wrote:

Hello group,

does anyone have had any luck with hosting qemu kvm images resided on BTRFS 
filesystem while serving
the volume via iSCSI?

I encouraged some unidentified problem and I am able to replicate it. Basically 
the NTFS filesystem
inside RAW image gets corrupted every time when Windows guest boots. What is 
weired is that changing
filesystem for ext4 or xfs solves the issue.

The problem replication looks as follows:
1) run chkdsk on the guest to make sure the filesystem structure is in good 
shape,
2) shut down the VM via libvirtd,
3) rsync changes between source and backup image,
4) generate SHA1 for backup and original and compare it,
5) try to run guest on the backup image, I was able to boot windows once for 
ten times, every time
after reboot NTFS' chkdsk finds problems with filesystem and the VM is unable 
to boot again.

What am I missing?

VM disk config:

 
   




cache=none uses O_DIRECT, and that's the source of the issue with VM
images on Btrfs. Details are in the list archive.

I'm not really sure what you want to use with Windows in this
particular case, probably not cache=unsafe though. I'd say give
writethrough a shot and see how it affects performance and fixes this
problem.

cache=writethrough is probably going to be the best option, unless you 
want to switch to cache=writeback and disable write caching in Windows 
(which from what I hear can actually give better performance than using 
cache=none).

--
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: ntfs -> qemu -> raw-image -> btrfs -> iscsi

2018-06-15 Thread Chris Murphy
On Fri, Jun 15, 2018 at 5:33 AM, ein  wrote:
> Hello group,
>
> does anyone have had any luck with hosting qemu kvm images resided on BTRFS 
> filesystem while serving
> the volume via iSCSI?
>
> I encouraged some unidentified problem and I am able to replicate it. 
> Basically the NTFS filesystem
> inside RAW image gets corrupted every time when Windows guest boots. What is 
> weired is that changing
> filesystem for ext4 or xfs solves the issue.
>
> The problem replication looks as follows:
> 1) run chkdsk on the guest to make sure the filesystem structure is in good 
> shape,
> 2) shut down the VM via libvirtd,
> 3) rsync changes between source and backup image,
> 4) generate SHA1 for backup and original and compare it,
> 5) try to run guest on the backup image, I was able to boot windows once for 
> ten times, every time
> after reboot NTFS' chkdsk finds problems with filesystem and the VM is unable 
> to boot again.
>
> What am I missing?
>
> VM disk config:
>
> 
>   



cache=none uses O_DIRECT, and that's the source of the issue with VM
images on Btrfs. Details are in the list archive.

I'm not really sure what you want to use with Windows in this
particular case, probably not cache=unsafe though. I'd say give
writethrough a shot and see how it affects performance and fixes this
problem.





-- 
Chris Murphy
--
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


ntfs -> qemu -> raw-image -> btrfs -> iscsi

2018-06-15 Thread ein
Hello group,

does anyone have had any luck with hosting qemu kvm images resided on BTRFS 
filesystem while serving
the volume via iSCSI?

I encouraged some unidentified problem and I am able to replicate it. Basically 
the NTFS filesystem
inside RAW image gets corrupted every time when Windows guest boots. What is 
weired is that changing
filesystem for ext4 or xfs solves the issue.

The problem replication looks as follows:
1) run chkdsk on the guest to make sure the filesystem structure is in good 
shape,
2) shut down the VM via libvirtd,
3) rsync changes between source and backup image,
4) generate SHA1 for backup and original and compare it,
5) try to run guest on the backup image, I was able to boot windows once for 
ten times, every time
after reboot NTFS' chkdsk finds problems with filesystem and the VM is unable 
to boot again.

What am I missing?

VM disk config:

    
  
  
  
  
  
    

Initiator side:

root@initiator:~# btrfs version
btrfs-progs v4.13.3
root@initiator:~# uname -a
Linux initiator 4.15.0-0.bpo.2-amd64 #1 SMP Debian 4.15.11-1~bpo9+1 
(2018-04-07) x86_64 GNU/Linux
root@initiator:~# btrfs version
btrfs-progs v4.13.3
root@initiator:~# cat /etc/debian_version
9.4
root@initiator:~# iscsid -v
iscsid version 2.0-874

BTRFS mount options:
_netdev,noatime,nodiratime,compress=lzo

Target side:

root@target:~# dpkg -l | grep iscsi
ii  iscsitarget 1.4.20.2-10.1  armel    
iSCSI Enterprise
Target userland tools
root@target:~# uname -a
Linux target 2.6.31.8 Mon Nov 23 04:30:20 CET 2015 v0.0.9 Mon Nov 23 04:30:20 
CET 2015 armv5tel
GNU/Linux

PS. There's nothing interesting in dmsg, besides (target side):
iscsi_trgt: scsi_cmnd_start(1045) Unsupported 85
iscsi_trgt: cmnd_skip_pdu(459) 5e00 1c 85 0
Which seems to be harmless and is probably generated by smartd.




--
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