Re: CIFS and data integrity
Martin Steigerwald Martin at lichtvoll.de writes: Hi Mark, Could you please try it that way: snip to make really obnoxious Gmane submission rules satisfied If the issue does not trigger with zeros, then use sha1sum your database backup file and then copy it and sha1sum it again. Thats just to verify the whole thing a bit more. Just to make sure also copy the file locally and verify sha1sum. It might be an issue local to your client. Thanks Martin, I will try these steps over the next day or two and post back here. Appreciate your taking the time to help. Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20120803t155926-...@post.gmane.org
Re: CIFS and data integrity
Am Sonntag, 29. Juli 2012 schrieb Mark Fletcher: Ahoy the list! Hi Mark, I use a Buffalo 4TB NAS using RAID which I mount from my Debian Wheezy AMD64 running on a self-built Intel Core i7 920-based machine. I want to be able to read and write the NAS from the Linux machine with minimum fuss. I also run a virtual Win7 guest on my Linux host, and want to be able to access the NAS from there also. I explicitly mount the NAS from the Linux host when I want it, and just access it from the Windows guest using Windows Explorer by referring to the NAS by its network name. I wouldn't _object_ to being able to auto-mount the NAS on boot of the host, as long as doing so doesn't cause untold hassle if the NAS is not available. One purpose of having the NAS is a place to store backups as protection against disk crashes on the Linux host, VM disasters, etc. Currently I mount the NAS on my Linux box using the following command as root. I am wondering if there is something wrong with this command as I will explain in a moment: mount -t cifs network path of NAS/share -o guest /mnt/nas After having done this, I can read data on the nas as any user by referring to /mnt/nas. It seems that to write I have to be root, which is inconvenient and something I'd rather avoid but not a disaster. It might be that the Samba server on the NAS – I bet Buffalo uses Samba here – might not return ownership information. In that case, you can make all files owned by a certain user with the uid/gid mount options. See manpage of mount.cifs. The issue is this: It seems that data I write there after mounting is not maintaining 100% fidelity. Here's an example: Dump a mysql database I have on my Linux host: mysqldump yahdahyahdahyahdah /opt/recovery/mysql20120725.sql Then bzip2 the puppy: cd /opt/recovery bzip2 mysql20120725.sql Test the correctness of the archive bzip2 -t mysql20120725.sql.bz2 (One time I also extracted it all again to a different directory and diffed with the original to make sure it was good and could be extracted back to the original) This produces a demonstrably-correct compressed archive of my db backup, about 150MB in size. Now copy that to the NAS: cp mysql20120725.sql.bz2 /mnt/nas/dbbackup (directory /dbbackup already existed on the NAS) That copy operation results in a file on the NAS that is identical in size to the one I copied. cd /mnt/nas/dbbackup bzip2 -t mysql20120725.sql.bz2 ... results in a failed test saying the archive is corrupted. Fair enough, I thought, perhaps bzip2 doesn't like operating over the network. So I then copied the backup file back to a different location on the host, bzip2 -t 'd it there, and got the same error. Could you please try it that way: dd if=/dev/zero of=lotsofszeros bs=1M count=10 sha1sum lotsofszeros cp lotsofzeros /mnt/nas/ sha1sum lotsofszeros With hd or xxd you could get a hexdump. If the issue does not trigger with zeros, then use sha1sum your database backup file and then copy it and sha1sum it again. Thats just to verify the whole thing a bit more. Just to make sure also copy the file locally and verify sha1sum. It might be an issue local to your client. It looks like what got stored on the NAS is not exactly what was originally on the host. This is a huge problem for me as it means I can't rely on backups dumped on that device. Is there something wrong with the way I am mounting the NAS that is leading to this? As you have Wheezy I assume you use kernel 3.2. As to what I have seen that is stable with CIFS, but I didn´t specifically test for data integrity either. But the Buffalo NAS might be using some real old stuff. I doubt they would sell something that doesn´t store data correctly. But it might be… I would check whether there is a firmware update. If that does not help I would check what the Buffalo NAS has to say about the RAID integrity and the harddisks. If thats okay, then you may consider putting a Debian onto the NAS. As to my knowledge this should be possible at least with certain models. But I am not sure whether only chroot or a complete replacement is possible. A complete replacement would be better in order to get a more recent kernel onto the box. (Now thats why I want something that I can install Debian too and do it all by myself.) Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201208012104.09407.mar...@lichtvoll.de
Re: CIFS and data integrity ; Sorry for the noise
On Tue, 31 Jul 2012 01:15:28 + (UTC) Mark Fletcher mark2...@gmail.com wrote: ... compatibility. I have heard of people wresting their NAS out of the grasp of the OS it comes with and installing Linux on it, presumably by mucking about with firmware etc, but I have never attempted to do any such thing as I would probably screw it up :-) So it is running whatever it was running when it left the factory. IIUC, NAS hacking is usually done to units that ship with linux, just a locked down / semi-proprietary version. The hacking enables the unit to run some more or less standard distribution. Celejar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120731220103.0073eedd.cele...@gmail.com
Re: CIFS and data integrity
Joe joe at jretrading.com writes: On Mon, 30 Jul 2012 01:50:14 +0900 Mark Fletcher mark27q1 at gmail.com wrote: It looks like what got stored on the NAS is not exactly what was originally on the host. This is a huge problem for me as it means I can't rely on backups dumped on that device. Is there something wrong with the way I am mounting the NAS that is leading to this? Probably. I'd guess it is a matter of permissions. If you create the archive elsewhere, copy it to the NAS, copy it back again, presumably there is no difficulty. I also use a Buffalo NAS, but my backups are created on my server, then copied. It is possible that if the compression and expansion is done on the NAS, that a temp file involved may not have the correct permissions to write, or more likely, amend. But is your backup not running under cron as root? I put the exact commands I was executing in my original post. There's no job involved, I am typing these commands at the command prompt. I'll bring a job into it once it works reliably. If you read my original post, you can see I create the archive on the host's local disk, test it to make sure it is good, and then copy it to the NAS in a separate operation. I use the cp command to do the copy. I'm inclined to rule out a bug in the cp command, which leaves something about the way the data is being transferred to my NAS. Hence my concern about whether my mount command (again, see details in my original post) was correct. And yes, to answer someone else's question, this is reproducible, reliably, every time. The copy on the NAS is always the same length as the copy on the host's local disk, but diff says they are two different binary files and the one on the NAS cannot be extracted. Thanks Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20120730t085028-...@post.gmane.org
Re: CIFS and data integrity
On 20120730_065640, Mark Fletcher wrote: Joe joe at jretrading.com writes: On Mon, 30 Jul 2012 01:50:14 +0900 Mark Fletcher mark27q1 at gmail.com wrote: It looks like what got stored on the NAS is not exactly what was originally on the host. This is a huge problem for me as it means I can't rely on backups dumped on that device. Is there something wrong with the way I am mounting the NAS that is leading to this? Probably. I'd guess it is a matter of permissions. If you create the archive elsewhere, copy it to the NAS, copy it back again, presumably there is no difficulty. I also use a Buffalo NAS, but my backups are created on my server, then copied. It is possible that if the compression and expansion is done on the NAS, that a temp file involved may not have the correct permissions to write, or more likely, amend. But is your backup not running under cron as root? I put the exact commands I was executing in my original post. There's no job involved, I am typing these commands at the command prompt. I'll bring a job into it once it works reliably. If you read my original post, you can see I create the archive on the host's local disk, test it to make sure it is good, and then copy it to the NAS in a separate operation. I use the cp command to do the copy. I'm inclined to rule out a bug in the cp command, which leaves something about the way the data is being transferred to my NAS. Hence my concern about whether my mount command (again, see details in my original post) was correct. And yes, to answer someone else's question, this is reproducible, reliably, every time. The copy on the NAS is always the same length as the copy on the host's local disk, but diff says they are two different binary files and the one on the NAS cannot be extracted. A quick way to by-pass the permissions issue is to log in as super-user root, and type your commands and tests as root. As I understand it, root is unstoppable. That is why it is so dangerous to use it in day-to-day mucking about. A moments inattention and real damaged is done. But... as a test, and you are testing, use root. -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120730182542.ga22...@big.lan.gnu
Re: CIFS and data integrity ; Sorry for the noise
On 20120730_122543, Paul E Condon wrote: On 20120730_065640, Mark Fletcher wrote: Joe joe at jretrading.com writes: On Mon, 30 Jul 2012 01:50:14 +0900 Mark Fletcher mark27q1 at gmail.com wrote: It looks like what got stored on the NAS is not exactly what was originally on the host. This is a huge problem for me as it means I can't rely on backups dumped on that device. Is there something wrong with the way I am mounting the NAS that is leading to this? Probably. I'd guess it is a matter of permissions. If you create the archive elsewhere, copy it to the NAS, copy it back again, presumably there is no difficulty. I also use a Buffalo NAS, but my backups are created on my server, then copied. It is possible that if the compression and expansion is done on the NAS, that a temp file involved may not have the correct permissions to write, or more likely, amend. But is your backup not running under cron as root? I put the exact commands I was executing in my original post. There's no job involved, I am typing these commands at the command prompt. I'll bring a job into it once it works reliably. If you read my original post, you can see I create the archive on the host's local disk, test it to make sure it is good, and then copy it to the NAS in a separate operation. I use the cp command to do the copy. I'm inclined to rule out a bug in the cp command, which leaves something about the way the data is being transferred to my NAS. Hence my concern about whether my mount command (again, see details in my original post) was correct. And yes, to answer someone else's question, this is reproducible, reliably, every time. The copy on the NAS is always the same length as the copy on the host's local disk, but diff says they are two different binary files and the one on the NAS cannot be extracted. A quick way to by-pass the permissions issue is to log in as super-user root, and type your commands and tests as root. As I understand it, root is unstoppable. That is why it is so dangerous to use it in day-to-day mucking about. A moments inattention and real damaged is done. But... as a test, and you are testing, use root. Having posted this, which I thought was reasonable, I went and looked at the archives to see what OP (Mark Fletcher) had written. It turns out that all of his investigation was done using commands typed in as root. For me, this thread is a real puzzle. And very scary. Mark: How old is your NAS? What brand? Is it likely that it uses Linux-based open/free software? What vintage? (best guess). IMHO, something bad is happening as we rush into the future. Layers of software can cover bugs in basic functionality. Complexity beyond human comprehension. -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120730200934.gb22...@big.lan.gnu
Re: CIFS and data integrity ; Sorry for the noise
On 30/07/12 04:09 PM, Paul E Condon wrote: On 20120730_122543, Paul E Condon wrote: On 20120730_065640, Mark Fletcher wrote: Joejoeat jretrading.com writes: On Mon, 30 Jul 2012 01:50:14 +0900 Mark Fletchermark27q1at gmail.com wrote: It looks like what got stored on the NAS is not exactly what was originally on the host. This is a huge problem for me as it means I can't rely on backups dumped on that device. Is there something wrong with the way I am mounting the NAS that is leading to this? Probably. I'd guess it is a matter of permissions. If you create the archive elsewhere, copy it to the NAS, copy it back again, presumably there is no difficulty. I also use a Buffalo NAS, but my backups are created on my server, then copied. It is possible that if the compression and expansion is done on the NAS, that a temp file involved may not have the correct permissions to write, or more likely, amend. But is your backup not running under cron as root? I put the exact commands I was executing in my original post. There's no job involved, I am typing these commands at the command prompt. I'll bring a job into it once it works reliably. If you read my original post, you can see I create the archive on the host's local disk, test it to make sure it is good, and then copy it to the NAS in a separate operation. I use the cp command to do the copy. I'm inclined to rule out a bug in the cp command, which leaves something about the way the data is being transferred to my NAS. Hence my concern about whether my mount command (again, see details in my original post) was correct. And yes, to answer someone else's question, this is reproducible, reliably, every time. The copy on the NAS is always the same length as the copy on the host's local disk, but diff says they are two different binary files and the one on the NAS cannot be extracted. A quick way to by-pass the permissions issue is to log in as super-user root, and type your commands and tests as root. As I understand it, root is unstoppable. That is why it is so dangerous to use it in day-to-day mucking about. A moments inattention and real damaged is done. But... as a test, and you are testing, use root. Having posted this, which I thought was reasonable, I went and looked at the archives to see what OP (Mark Fletcher) had written. It turns out that all of his investigation was done using commands typed in as root. For me, this thread is a real puzzle. And very scary. Mark: How old is your NAS? What brand? Is it likely that it uses Linux-based open/free software? What vintage? (best guess). IMHO, something bad is happening as we rush into the future. Layers of software can cover bugs in basic functionality. Complexity beyond human comprehension. May I suggest that it could be nothing more than a defective network card or cable? It may also be the result of some other hardware error. That's why I suggested doing a file cmp on the files and using rsync. I find exactly the same problem when backing up to rewritable optical media. You can't always trust the writes to work properly. Always to a verify and correct if the files are at all important. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5016eb67.70...@rogers.com
Re: CIFS and data integrity ; Sorry for the noise
Paul E Condon pecondon at mesanetworks.net writes: Having posted this, which I thought was reasonable, I went and looked at the archives to see what OP (Mark Fletcher) had written. It turns out that all of his investigation was done using commands typed in as root. For me, this thread is a real puzzle. And very scary. Mark: How old is your NAS? What brand? Is it likely that it uses Linux-based open/free software? What vintage? (best guess). IMHO, something bad is happening as we rush into the future. Layers of software can cover bugs in basic functionality. Complexity beyond human comprehension. Paul -- The NAS is a Buffalo LinkStation 4TB NAS configured to do RAID giving me 2TB of storage. I bought myself it for Christmas from Amazon.co.jp (I live in Japan) at Christmas 2010. I don't know what OS it will be running but doubt it will be Linux since Buffalo will be aiming to maximise Windows compatibility. I have heard of people wresting their NAS out of the grasp of the OS it comes with and installing Linux on it, presumably by mucking about with firmware etc, but I have never attempted to do any such thing as I would probably screw it up :-) So it is running whatever it was running when it left the factory. I'm simultaneously glad that someone else is as unnerved by this happening as I am, and increasingly nervous that the issue isn't inspiring oh that old chestnut reaction in list readers... :-) Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20120731t030407-...@post.gmane.org
Re: CIFS and data integrity ; Sorry for the noise
On Tue, 31 Jul 2012, Mark Fletcher wrote: Paul E Condon pecondon at mesanetworks.net writes: Having posted this, which I thought was reasonable, I went and looked at the archives to see what OP (Mark Fletcher) had written. It turns out that all of his investigation was done using commands typed in as root. For me, this thread is a real puzzle. And very scary. Mark: How old is your NAS? What brand? Is it likely that it uses Linux-based open/free software? What vintage? (best guess). IMHO, something bad is happening as we rush into the future. Layers of software can cover bugs in basic functionality. Complexity beyond human comprehension. Paul -- The NAS is a Buffalo LinkStation 4TB NAS configured to do RAID giving me 2TB of storage. I bought myself it for Christmas from Amazon.co.jp (I live in Japan) at Christmas 2010. I don't know what OS it will be running but doubt it will be Linux since Buffalo will be aiming to maximise Windows compatibility. I have heard of people wresting their NAS out of the grasp of the OS it comes with and installing Linux on it, presumably by mucking about with firmware etc, but I have never attempted to do any such thing as I would probably screw it up :-) So it is running whatever it was running when it left the factory. I'm simultaneously glad that someone else is as unnerved by this happening as I am, and increasingly nervous that the issue isn't inspiring oh that old chestnut reaction in list readers... :-) Well... there is an awlful lot of CIFS and NFS-related fixes in the kernel stable queue. Check that. Also make sure it is not your NIC driver or memory (or the NAS' memory) that went bad... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120731012712.gb25...@khazad-dum.debian.net
Re: CIFS and data integrity ; Sorry for the noise
Henrique de Moraes Holschuh hmh at debian.org writes: Well... there is an awlful lot of CIFS and NFS-related fixes in the kernel stable queue. Check that. Also make sure it is not your NIC driver or memory (or the NAS' memory) that went bad... I wondered about this too -- and the defective cable / NIC idea posted by Gary earlier. But I would have expected that network card / driver / memory issues would result in a failed transfer that would either end in tears (error messages) or would cause part of the transfer to be retried and thus take longer but eventually end with correct data having been transferred. What's giving me the heebie-jeebies (if you'll pardon the technial term) about this is that every software and hardware component seems to think that everything went swimmingly as far as I can tell, but the data on the target is nonetheless not correct. Mark -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20120731t044059-...@post.gmane.org
Re: CIFS and data integrity ; Sorry for the noise
On 31/07/12 13:15, Mark Fletcher wrote: Paul -- The NAS is a Buffalo LinkStation 4TB NAS configured to do RAID giving me 2TB of storage. I bought myself it for Christmas from Amazon.co.jp (I live in Japan) at Christmas 2010. I don't know what OS it will be running but doubt it will be Linux since Buffalo will be aiming to maximise Windows compatibility. http://opensource.buffalo.jp/gpl_storage.html I think it quite possibly is :-) Oldish though - 2.4.20 by the looks of it. Richard -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5017541a.2020...@walnut.gen.nz
Re: CIFS and data integrity
On 29/07/12 12:50 PM, Mark Fletcher wrote: Ahoy the list! I use a Buffalo 4TB NAS using RAID which I mount from my Debian Wheezy AMD64 running on a self-built Intel Core i7 920-based machine. I want to be able to read and write the NAS from the Linux machine with minimum fuss. I also run a virtual Win7 guest on my Linux host, and want to be able to access the NAS from there also. I explicitly mount the NAS from the Linux host when I want it, and just access it from the Windows guest using Windows Explorer by referring to the NAS by its network name. I wouldn't _object_ to being able to auto-mount the NAS on boot of the host, as long as doing so doesn't cause untold hassle if the NAS is not available. One purpose of having the NAS is a place to store backups as protection against disk crashes on the Linux host, VM disasters, etc. Currently I mount the NAS on my Linux box using the following command as root. I am wondering if there is something wrong with this command as I will explain in a moment: mount -t cifsnetwork path of NAS/share -o guest /mnt/nas After having done this, I can read data on the nas as any user by referring to /mnt/nas. It seems that to write I have to be root, which is inconvenient and something I'd rather avoid but not a disaster. The issue is this: It seems that data I write there after mounting is not maintaining 100% fidelity. Here's an example: Dump a mysql database I have on my Linux host: mysqldump yahdahyahdahyahdah /opt/recovery/mysql20120725.sql Then bzip2 the puppy: cd /opt/recovery bzip2 mysql20120725.sql Test the correctness of the archive bzip2 -t mysql20120725.sql.bz2 (One time I also extracted it all again to a different directory and diffed with the original to make sure it was good and could be extracted back to the original) This produces a demonstrably-correct compressed archive of my db backup, about 150MB in size. Now copy that to the NAS: cp mysql20120725.sql.bz2 /mnt/nas/dbbackup (directory /dbbackup already existed on the NAS) That copy operation results in a file on the NAS that is identical in size to the one I copied. cd /mnt/nas/dbbackup bzip2 -t mysql20120725.sql.bz2 ... results in a failed test saying the archive is corrupted. Fair enough, I thought, perhaps bzip2 doesn't like operating over the network. So I then copied the backup file back to a different location on the host, bzip2 -t 'd it there, and got the same error. It looks like what got stored on the NAS is not exactly what was originally on the host. This is a huge problem for me as it means I can't rely on backups dumped on that device. Is there something wrong with the way I am mounting the NAS that is leading to this? Thanks Is this repeatable? Have you tried doing a file cmp to verify the copy worked? I do this as a matter of course to ensure a good backup. Normally I prefer to use rsync across a network. Rsync will only copy the parts that have changed. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5015717e.2090...@rogers.com
Re: CIFS and data integrity
On Mon, 30 Jul 2012 01:50:14 +0900 Mark Fletcher mark2...@gmail.com wrote: It looks like what got stored on the NAS is not exactly what was originally on the host. This is a huge problem for me as it means I can't rely on backups dumped on that device. Is there something wrong with the way I am mounting the NAS that is leading to this? Probably. I'd guess it is a matter of permissions. If you create the archive elsewhere, copy it to the NAS, copy it back again, presumably there is no difficulty. I also use a Buffalo NAS, but my backups are created on my server, then copied. It is possible that if the compression and expansion is done on the NAS, that a temp file involved may not have the correct permissions to write, or more likely, amend. But is your backup not running under cron as root? Out of curiosity, I've just compressed and restored a 200MB folder on the NAS from Nautilus on my workstation, logged in as a normal user. I haven't confirmed the accuracy of the copy, but I got no error messages and I can read individual files. I can't delete either the archive or the restored directory, as they are owned by root and have -r-xrwSrwt and dr-xrwSrwt permissions respectively. These will be a function of the NAS cifs server, quite possibly samba. I have no problem deleting them while running mc as root. I've also archived a 285MB folder from the workstation to the NAS and restored it to the workstation, again without problems. I'm afraid I have rather lazy fstab entries for the NAS shares, which I probably ought to fix, but they are also shared with Windows machines and I recall having a rather difficult time getting everything working at the same time. It is difficult working up the enthusiasm to have another go with the aim of a more secure result. //buffalo/Backups /mnt/buffalo/Backups cifsuser,guest,noperm,dir_mode=0x777,file_mode=0x777,rw This should at least provide a starting point. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120729203246.5e0b2...@jretrading.com
