FreeBSD 9.1 not liking my NTFS formatted hybrid drive

A

AZ_Curt

Good day,

I believe this is the right forum for this post. I have searched the forums here and have not found a solution; so I shall post my problem as follows.

The title say it all. I have installed 9.1 on my computer in a dual boot configuration with windows 7. Each OS has its separate drive, and GRUB2 determines which OS I boot into.

There are 4 drives in this system, two are standard HD's (one for freebsd FreeBSD 9.1), the Windows drive is a SSD and I have a hybrid drive for all my Windows applications.

When I boot into 9.1 x64 it recognizes and can mount all my drives except for the hybrid drive. When I reboot into Windows, the MBR, FAT and a lot of the data is gone from the hybrid. I have no problems with the hybrid drive in this configuration using OpenSUSE or Fedora. But I would much prefer to return to FreeBSD.

I should add two additional items.

1 - I initially noticed this occurring in PC-BSD 9.1 x64. As it is based on FreeBSD, I installed FreeBSD 9.1 x64 to see it it solved my problem. No joy, the data on the hybrid drive was still lost.

2 - I only noticed this after the FreeBSD and PC-BSD were installed and updated packages applied. So I can't honestly say if it was an updated package that caused the problem or not.

Has anyone else experienced this problem, and/or know of a fix as I cant afford to reinstall / restore everything to my hybrid drive every time I reboot into Winsdows.

Here is some basic system information

MB: Biostar TA990FXE, uEFI BIOS (AMI V. 04.06.04)
Pro: ADM FX-8350
Drives:
Seagate ST1000VX000-9YW162 - NTFS
INTEL SSDSC2CT240A3 - NTFS
Seagate ST750LX003-1AC154 - NTFS HYBRID DRIVE
Western Digital WDC WD6400AAKS-22A7B0 - ZFS

Thanks.
 
Thanks Dowser for the reply.

Will check that furefs is up to date. I was also going to try to mount the drive with fstab using ro,noauto. I really have no need to read/write to this particular drive outside of windoze, so not having it available is no big deal.

I did perform a fresh install of PC BSD. When the system rebooted after the install, I changed to the windoze drive to check on the hybrid drive (Seagate) and all data was still there. I disconnected the drive prior to booting into PC BSD and performing updates etc. Will reconnect the drive after I verify fusefs and make the fstab mount entry and update.
 
Do you really power off the Win7 session or do you put it to hibernation? There is a lot of problems with that state, as Windows tries to cache some data in the hibernation file then, and this can seriously mess the FS. Shutting down windows currently may go into hibernation, there was a change in that policy IIRC.
 
Crivens said:
Do you really power off the Win7 session or do you put it to hibernation? There is a lot of problems with that state, as Windows tries to cache some data in the hibernation file then, and this can seriously mess the FS. Shutting down windows currently may go into hibernation, there was a change in that policy IIRC.
Click to expand...

I only use windoze for gaming. *BSD is used for everything else. So when I am done playing, I tell windoze to reboot and select the *BSD drive. Each OS has its own drive. I prefer it that way.

I do not use hibernation for anything except my screen.

I did do a fresh install of PC BSD and decided to change boot drives via BIOS. So far I have not had any problems with NTFS. Then again I have not attempted to mount any drives not being used for *BSD.

I have narrowed down the problem (possibly) to one of two possibility's. Or a combination of both.

1. A delayed write to the Seagate hybrid drive by the fusefs-3g cache during a reboot or powering down.

2. fusefs wrote data to the hybrid drive's cache (8G I believe) which was not written to the actual platters. fusefs thought the data was written, when in fact it was in the hybrid cache while the system was powered down.

As I only have the problem with the hybrid drive I am leaning more towards #2; but #1 could also be a factor.
 
Build BSD in another machine. Dual booting spins the other drives needlessly.
I can't power down this network, not so easily. I can't play quake against myself, either. For data transfer, or storage, there's samba. For remote
login there's vnc. Risking data, against a write failure, or any other problem is asking for trouble. Lots of time consuming, labor intensive trouble. Add this to your login script, usually a ".cshrc" file in your
home or root dir. [ alias off "sync && sync && shutdown -p now" ] "Without
the brackets". syncing twice seems to give it a bit of time to write the memory to the drive(s). With today's "gigs" of ram, that can take a few seconds or more. A 2 Ghz cpu can take 12 seconds to flush 2 gig of memory, and with that, a 100Mb/sec drive can take 20 seconds to write that much.
That's 32 seconds, and then the normal shutdown starts. A seperate box would be safer. Good luck. If you added the line to the login script, you can now
just type "off" and let Bsd sort out the memory cache as it shuts down.
 
FreeBSD usually takes care of the file system caches itself. That's what the syncing of vnodes message counting down at shutdown is about.
What the system can not do is to force the drive to write that amount of data out to the spinning rust layer fast enough. Therefore, shutdown -p, which powers off the machine, can destroy that data. Using shutdown -h, and then manually powering it off after several seconds, should be safer.
I think this will become more and more of a problem as the interface speed of drives grows, along with on-disk cache systems. As long as the platter system can not keep up, the window of opportunity for desaster to strike opens wider and wider.
 
Crivens said:
(Snip)

I think this will become more and more of a problem as the interface speed of drives grows, along with on-disk cache systems. As long as the platter system can not keep up, the window of opportunity for desaster to strike opens wider and wider.
Click to expand...

After going over this and testing on my machine I believe this is the root cause of my (and potentially other folks) problem with the hybrid drive. All other drives, to include my SSD get synched without any problem at shutdown. It is only the hybrid which has a problem.

With 8G of SLC NAND flash, a ton of stuff can be sitting there waiting to be written to the platters. And if *BSD thinks the data has been written to the drive even though its in the NAND flash; the data is lost and the drive corrupted. Not 100% sure about all this, but unless someone has another theory it is the most likely suspect.

@Dowser - Not overly concerned with the drives spinning needlessly here. I have a few spares and a good back-up machine/storage in my old Sun Blade 1500 with Solaris 9. It does a lot more than just store my backups tho :)

Been out of the SysAdmin business long enough to forget critical thinking when it comes to troubleshooting. Thanks all for helping me clear the cob webs and come to the root (I think) of the problem.
 
I pasted your drive model # into google. The top 10 results show 5+ complaints. It's cache is only 35 Meg, nothing close to even 1 Gig. It's
"smart" feature seems to have a problem, and owners are looking for a firmware update. Check that out and/or get another model/refund from
your store. BTW, Mac users are complaining about it making their laptops
hot, and killing their batteries. BSD doesn't seem to be the the issue
with it, nor your MS-win7, so good luck, again.
 
I miss spoke when I referred to the SLC NAND flash as a cache.

As I said, after some research it became apparent it was the 8G of flash for "Storage of frequently used data;" otherwise known as the "SMART" feature that caused the problem by failing to write data to the platters. Thereby corrupting the drive. In short, I placed the cause of the problem squarely on the drive and the "smart" feature, not BSD, Linux or windoze.

In short, if you have a hybrid drive back it up frequently (or replace the drive). The drive is great for what it does, but the risk of loosing data trumps the drives features.
 
SMART or S.M.A.R.T.?
S.M.A.R.T. is something different from what you mean.

I rather think that the drive has a RAM cache and the NAND funtions something like the cache device in ZFS or this ready boost for Windows. But the drive would need to write the RAM cache to flash when shutting down and reload+replay it on the next power up. But I think the disk is using more power due to more logic involved, thus the buffer capacitators are not sufficient. I'd place the blame on that, maybe you can try some capacitators wired to the power connectors of the drive to buy it more time for writing back the RAM cache data.
 
Been out of the field for so long the technology got away from me. Whatever the drive uses and however it uses it to read, write and store data into and between the RAM cache, NAND flash and the platters is the root cause. As long as that particular drive is not mounted rw, the data integrity is preserved.

Been using the drive for a while with no problems in SlackWare and windoze, and thought it might have been an issue with *BSD. Turns out it was not the (any) OS at all but the drive technology. However its termed :)

Now if I need anything off of it, I will manually mount it ro as that causes absolutely no problems.
 
You must log in or register to reply here.
Back
Top