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
Reply to: