disk pool throwing alert

[sretalla]

/usr/sbin/zfs diff tank/media@media bunker/media@media

OK, try it against the live filesystem:

/usr/sbin/zfs diff tank/media@media bunker/media

 

[samarium]

OK, try it against the live filesystem:

/usr/sbin/zfs diff tank/media@media bunker/media

not going to fly @sretalla must be common dataset

zfs diff tank/medai@meda tank/media

will show if tank/media has been updated since the snapshot @media

 

[georgelza]

Executing
tmux new-session -d -s dif '/usr/sbin/zfs diff tank/media@media tank/media'

G

 

[sretalla]

True enough... it really should just be as simple as that, but I guess zfs is trying to tell us to trust it and not verify.

 

[sretalla]

I would suggest you just use filezilla or some other SCP tool to do a visual once-over on the data and call it a day.

 

[samarium]

@sretella hope you picked up the bit where the rsync -auv path options were slightly wrong and causing a duplication of the data, something to keep in mind not to be bitten again. I have bitten myself before which is why is is on my mine when I use rsync.

 

[sretalla]

Obviously if you don't line paths up, you're going to create problems in write mode...

But if you don't spot the problem, you're still going to think there's a bunch of missing files.

I was looking at other ways, but it seems "whole filesystem checksum" is where it would be to compare a transferred ZFS filesystem to the original. (using a tool like hashdeep https://github.com/jessek/hashdeep)

That wouldn't serve much purpose here other than consume a lot of time and electricity.

 

[samarium]

As far as I know, if the zfs recv completes OK then the snapshot is created and it is good. If zfs recv fails then the snapshot is not created, and the data on the recv end is flushed. Unless you use the special flag to resume interrupted transfers, which isn't relevant in this case.

As for hashdeep, if I really had do I probably would just cd /path1; find . -type f -print0 | xargs -0rn 100 md5sum | sort > /tmp/1 and again for path2 and diff the tmp files. As you said it would chew a lot of cpu, and for zfs send/recv is a pointless exercise.

 

[georgelza]

hmmmmm.....

ye I don't know how to proceed, allot of to and throw... discussions.

My intension is once the copy has been confirmed good on bunker/media to then delete the source tank/media as I need to unconfigure that diskpool and do some write/destructive testing on the disks, eventually it will be recreated as a 5 wide RaidZ2 diskpool, at which time bunker/media will be moved back.

G

 

[sretalla]

Like I said, kick the tyres a bit with something like FileZilla, just do a few random checks that files are where they should be.

zfs will have reported an error during the transfer (or failed completely) if the content wasn't the same.

If you're really wanting some kind of guarantee, we can go back to getting the rsync syntax right and do it that way if it helps you sleep better.

 

[georgelza]

FYI

zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT

bunker 8.54T 5.87T 128K /mnt/bunker
bunker/TimeMachine_new 1.64T 5.87T 181K /mnt/bunker/TimeMachine_new
bunker/TimeMachine_new/george 1.64T 5.87T 1.64T /mnt/bunker/TimeMachine_new/george
bunker/home 467G 5.87T 139K /mnt/bunker/home
bunker/home/george 423G 5.87T 423G /mnt/bunker/home/george
bunker/home/zelda 43.7G 5.87T 43.7G /mnt/bunker/home/zelda
bunker/media 6.44T 5.87T 6.44T /mnt/bunker/media
bunker/media@media 0B - 6.44T -
tank 6.44T 716G 128K /mnt/tank
tank/.system 1.56G 716G 1.35G legacy
tank/.system/configs-7bdf26d378f44463a02df9c5bc4d0ea3 81.0M 716G 81.0M legacy
tank/.system/cores 128K 1024M 128K legacy
tank/.system/ctdb_shared_vol 128K 716G 128K legacy
tank/.system/glusterd 128K 716G 128K legacy
tank/.system/rrd-7bdf26d378f44463a02df9c5bc4d0ea3 110M 716G 110M legacy
tank/.system/samba4 821K 716G 821K legacy
tank/.system/services 128K 716G 128K legacy
tank/.system/syslog-7bdf26d378f44463a02df9c5bc4d0ea3 28.4M 716G 28.4M legacy
tank/.system/webui 128K 716G 128K legacy
tank/media 6.44T 716G 6.44T /mnt/tank/media
tank/media@media 8.65M - 6.44T -

 

[georgelza]

and

zfs diff tank/media@media tank/media

came back with a empty line

G

 

[sretalla]

zfs diff tank/media@media tank/media

came back with a empty line

Means they are the same.

 

[sretalla]

I think you're fine to proceed with bunker as the location of media now.

Make sure to move your system dataset off tank before getting rid of it.

 

[georgelza]

so was thinking...
create a snapshot of bunker/media now.
then compare this snapshot against the source created on tank/media

/usr/sbin/zfs snapshot -r bunker/media@snap

$ zfs diff tank/media@media bunker/media@snap
Not an earlier snapshot from the same fs: invalid name

 

[georgelza]

I'll reconfigure my plex and SMB and NFS shares to point to bunker/media.

G

 

[georgelza]

Means they are the same.

Hi there

Yes, but look at what we comparing, we comparing the source FS to the snapshot taken of it, which should be the same as I said I've not made any changes.

I want to compare my source, be that the FS or the snapshot against the target bunker/media

 

[georgelza]

I think you're fine to proceed with bunker as the location of media now.

Make sure to move your system dataset off tank before getting rid of it.

thanks, forgot about that one ;)

G

 

[sretalla]

I want to compare my source, be that the FS or the snapshot against the target bunker/media

So we're back to getting the rsync command right to do that.

 

[georgelza]

i'm wanting to make sure everything is there... however.
when i was last given a command to use to check it, expecting a zero dif (and as per samarium, said, if it finished without errors all should have been good) we ended with allot of data/lines reported as not there. so we saying trust it, but then when we checked we find missing, so which is wrong,

G