* FUA and DPO unsupported using sata_nv on MCP55?
@ 2007-04-05 13:13 Eamonn Hamilton
2007-04-09 7:45 ` Tejun Heo
0 siblings, 1 reply; 3+ messages in thread
From: Eamonn Hamilton @ 2007-04-05 13:13 UTC (permalink / raw)
To: linux-ide
Hi,
I've got a couple of Samsung HD501LJ drives attached to a KN9 Ultra
board using the MCp55 chipset, and I'm getting an NCQ depth of 0
reported at boot, which as I understand it is because support for NCQ
isn't in the sata_nv driver yet for this chipset.
ata1.00: ATA-7, max UDMA7, 976773168 sectors: LBA48 NCQ (depth 0/32)
ata2.00: ATA-7, max UDMA7, 976773168 sectors: LBA48 NCQ (depth 0/32)
Later in the boot, however, I get
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
which as I understand it means my data ( plus the wifes picture
archive! ) is at risk, as I have write cache enabled and barrier support
is disabled because of the lack of FUA. Is this caused by my drives, or
is there something I need to enable?
Any hints gratefully received,
Eamonn
--
Eamonn Hamilton <eamonn.hamilton@saic.com>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: FUA and DPO unsupported using sata_nv on MCP55?
2007-04-05 13:13 FUA and DPO unsupported using sata_nv on MCP55? Eamonn Hamilton
@ 2007-04-09 7:45 ` Tejun Heo
2007-04-09 8:24 ` Eamonn Hamilton
0 siblings, 1 reply; 3+ messages in thread
From: Tejun Heo @ 2007-04-09 7:45 UTC (permalink / raw)
To: Eamonn Hamilton; +Cc: linux-ide
Eamonn Hamilton wrote:
> Hi,
>
> I've got a couple of Samsung HD501LJ drives attached to a KN9 Ultra
> board using the MCp55 chipset, and I'm getting an NCQ depth of 0
> reported at boot, which as I understand it is because support for NCQ
> isn't in the sata_nv driver yet for this chipset.
>
> ata1.00: ATA-7, max UDMA7, 976773168 sectors: LBA48 NCQ (depth 0/32)
> ata2.00: ATA-7, max UDMA7, 976773168 sectors: LBA48 NCQ (depth 0/32)
Yeap.
> Later in the boot, however, I get
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
>
> which as I understand it means my data ( plus the wifes picture
> archive! ) is at risk, as I have write cache enabled and barrier support
> is disabled because of the lack of FUA. Is this caused by my drives, or
> is there something I need to enable?
Nothing is in danger. FUA just speeds up barrier a tad bit. Doesn't
matter really.
--
tejun
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: FUA and DPO unsupported using sata_nv on MCP55?
2007-04-09 7:45 ` Tejun Heo
@ 2007-04-09 8:24 ` Eamonn Hamilton
0 siblings, 0 replies; 3+ messages in thread
From: Eamonn Hamilton @ 2007-04-09 8:24 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide
Hi,
I'm glad to hear that my data is looking safe, although my XFS
filesystem reports "Disabling barriers, not supported by underlying
device" when I try to mount a RAID-1 of these two disks. I guess it's
something to do with the software raid code?
Anyway, thanks for the help, it's always a pleasure :)
Oh, I don't suppose anybody has any idea when the NCQ support might go
into the sata_nv driver? I seem to recall it was being talked about
months ago?
Cheers,
Eamonn
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-04-09 8:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-04-05 13:13 FUA and DPO unsupported using sata_nv on MCP55? Eamonn Hamilton
2007-04-09 7:45 ` Tejun Heo
2007-04-09 8:24 ` Eamonn Hamilton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).