Re: [PATCH] st: implement sysfs based tape statistics v2
"Seymour, Shane M" writes: > Both of those things would have to be futures and require discussion - > the very original version cleared stats on a device open but I got > asked to keep it the stats cumulative so they would be more similar to > disk stats. Yes, this is a futures question. But in a perfect world, there'd be two sets of statistics, one cumulative since the last reboot and one that was cleared every time a tape was unloaded. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] st: implement sysfs based tape statistics v2
One feature of tape statistics is that they're as much about the *tape* as they are about the *drive*, which is uncommon for block devices. It might be useful to have a set of counters which is cleared every time a new tape is inserted into the drive. In particular, "bad reads since this tape was inserted" would be very useful for monitoring the quality of tapes. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: absurdly high "optimal_io_size" on Seagate SAS disk
> From: Chris Friesen > Also, I think it's wrong for filesystems and userspace to use it for > alignment. In E.4 and E.5 in the "sbc3r25.pdf" doc, it looks like they > use the optimal granularity field for alignment, not the optimal > transfer length. Everything you say suggests that "optimal transfer length" means "there is a penalty for doing transfers *larger* than this", but people have been treating it as "there is a penalty for doing transfers *smaller* than this". But the latter is the "optimal transfer length granularity". Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Large disk drives
> From: James Bottomley > > We really don't want to make the decision within the kernel of whether > we believe the partition size or the disk capacity. For these disk > problems we need it to be the former, but if we choose that always, > we'll get weird results on mispartitioned devices. > > The usual rule is no policy in the kernel and which to choose is policy, > so just export the knob (as Alan's patch does) and then let userspace > decide. I can see some significant advantages to setting up the hack in user-space, above the architectural ones: - We can get the user to confirm how big we think the disk is -- because its size is printed on the label of the disk. And if the partition table is unreadable in some way, the user can manually enter the size. - We can warn the user that the data path to his disk is deficient in not supporting which ever SCSI request, so that he knows to upgrade his hardware. There is one thing that seems like it might be a problem: We have to ensure that the SCSI driver can read the partition tables (in the standard locations) even if it doesn't know how big the disk is. Which leads me to wonder what happens if one reads /dev/sdX until one hits end-of file. People have written that we don't want to read the disk from locations beyond end-of-data because some disks react badly to out-of-range reads. But if that is so in general, there would be problems simply copying /dev/sdX. (Indeed, if all disks gave a proper error for out-of-range reads, a bisection search would find the size of the disk easily enough.) Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Large disk drives
> From: "Theodore Ts'o" > > On Wed, Nov 05, 2014 at 05:07:48PM +0100, James Bottomley wrote: > > > > OK, but I still don't understand how windows gets the partition table on > > there in the first place ... that must surely be some sort of guess the > > disk size hack. > > 99% of the time the partition table was provided by the drive > manufacturer; I would assume they have a way of doing that as a part > of their manufacturing processes that don't require an OS individually > running the equivalent of fdisk or gdisk on said drive. I would expect it as part of the manufacturer's testing process. After all, the disks are going to be plugged into a machine whose whole purpose is to run the disk through its paces, and the machine knows in advance exactly how big the disk is. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Large disk drives
> From: Alan Stern > I posted a patch to allow the user to override the reported capacity: > > http://marc.info/?l=linux-scsi&m=140993840113445&w=2 I see the patch, and I feel confident I could install it if I needed to. What command do I execute to "write to the capacity_override attribute", before I do "blockdev --rereadpt /dev/sdX"? Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Large disk drives
Replying to two messages at once: > Date: Tue, 4 Nov 2014 11:14:39 -0500 (EST) > From: Alan Stern > cc: "Dale R. Worley" , , > > > On Tue, 4 Nov 2014, James Bottomley wrote: > > > On Mon, 2014-11-03 at 16:06 -0500, Dale R. Worley wrote: > > > Was there any resolution as to how large disk drives would be handled > > > if their interface did not support the "capacity" request that would > > > tell how large they were? > > > > Realistically no ... unless someone comes up with a reliable heuristic > > to give us the size. I can understand why the linux-scsi project would not want to take up what is really a hack to work around a hardware deficiency. > I posted a patch to allow the user to override the reported capacity: > > http://marc.info/?l=linux-scsi&m=140993840113445&w=2 > > Nobody responded to it. > > > > Unfortunately, such devices work OK with Windows (since Windows trusts > > > what the partition table says), you can't just say to the salesperson > > > "It has to work on drives over 3 TB." > > > > This is a stopgap: your 3TB drive can be guessed as the 16 bit capacity > > plus 2TB, but the same won't happen for a 5TB device. Believing the > > partition table gives us a chicken and egg problem because something > > still has to get the partition table on to the device. > > > > I don't think "don't buy something that doesn't work" is a hugely > > unreasonable response to this. > > The problem is knowing beforehand whether it will work. Once you buy > the device and can test it, returning it is annoying and time-consuming > at best. Or as I would phrase it, How do you turn "Don't buy something that doesn't work!" into an algorithm? That is: I'm standing in MicroCenter, holding a box in my hand that contains a USB-to-SCSI adapter. How do I determine whether or not it supports large disks? The problem being that it *works with Windows*, so I can't just ask the friendly salesperson, Does this work with 3 terabyte disks? In my case, the Diablotek device works, while the Kingwin EZ-Connect does not, despite being labeled in essentially the same way. (Neither says that Linux is supported.) I admit that my problem may be my deficiency in dealing with the retail situation, as I'm a much better software engineer than shopper. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Large disk drives
Was there any resolution as to how large disk drives would be handled if their interface did not support the "capacity" request that would tell how large they were? Or as an alternative, is there any way to avoid buying USB-SCSI interfaces that do not support the large-capacity request? Unfortunately, such devices work OK with Windows (since Windows trusts what the partition table says), you can't just say to the salesperson "It has to work on drives over 3 TB." Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: James Bottomley > Before we embark on elaborate hacks, why don't we just make the capacity > writeable (by root) in sysfs from userspace (will require block change)? > We can then encode all the nasty heuristics (including gpt reading) in > userspace as a udev rule. Looking in from the outside, this makes sense to me. All the nasty hueristics can be put in userspace -- perhaps as even a special-purpose program, where we can directly warn the user as to what he's getting himself into. (I do not demand that this all work automatically.) And the hueristics can be improved easily, without kernel changes. The only gotcha that I see is that once the recorded device size is changed, the kernel may now consider the partition table to be valid, and should now parse it and set up the special device numbers for the partitions. So that needs to get triggered properly. I suppose there is some complexity if the block-handling layer already has blocks cached and the device size is reduced below the addresses of the cached blocks. But as long as the kernel doesn't crash or write blocks in incorrect places, I don't see that as a problem -- if you set the device size as less than the block numbers you've already written to, that's your problem. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: Alan Stern > Anyway, I can try writing a patch to add this capability. We'll see if > it can solve your problem. Unfortunately, I think there is genuine value in such a hack. E.g., I've got two USB-to-SATA adapters. One works correctly. One does not. But at this point, I can't attach both of my high-capacity disks to the laptop at the same time, which makes it difficult to bulk-transfer files from one to the other. If, for the deficient adapter, the kernel assumed the disk size was the end of the last partition (or the backup GPT partition table, if that follows), then I could use it for everything other than repartitioning. And that would make life easier. Thanks for trying, Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: Alan Stern > > On Fri, 29 Aug 2014, Matthew Dharm wrote: > > Is there an 'easy' way to override the detected size of a storage > > device from userspace? If we had that, someone could write a helper > > application which looked for this particular fubar and try to Do The > > Right Thing(tm), or at least offer the user some options. > > You mean, force a Media Change event and override the capacity reported > by the hardware? I'm not aware of any API for doing that, although it > probably wouldn't be too hard to add one. > > How would the user know what value to put in for the capacity? Unless > the drive had been hooked up to a different computer and the user > manually noted the correct capacity and typed it in, it would have to > be guesswork. The value would most sanely be extracted from the partition table. (After verifying that the partition table looks correct.) That seems to be what Windows does, and it seems to work consistently enough for Windows to trust that method. Or at least, it could take the disk size to be the end of the last partition, which would at least make all the partitions accessible. As somebody else hinted at, the userspace program could check the USB device against a list of device types known to have this problem. It could even verify that the SCSI-reported size matches the size reported by the partition table (modulo two-to-the-whatever) (at least for GPT tables, I don't know if MBR tables report the disk size). Do we have any way of knowing what algorithm Windows uses in this situation? Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: Alan Stern > If you try to repartition the drive under Windows using the deficient > adapter, you'll see that the problem still exists. It just doesn't > show up during normal use. So in summary, the Windows workaround is icky, but it allows any use but repartitioning to be one on the attached disk. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
What I find interesting is that Windows (at least, Windows 7 Professional) seems to be able to handle the deficient adapter. What I'd like to do is log the disk commands during the mounting sequence, preferably at both the SCSI and USB layers. Then at least we'll know exactly what the driver is doing. Are there kernel options to do this? Unfortunately, I don't know any way to log what Windows is doing with the drive. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
> From: James Bottomley > Did you try read capacity 16 on it? What happened? (the AS2105 rejects > read capacity 16, so there's no reliable way to deduce the capacity of > drives over 2TB). OK, I had to track down which package contains sg_readcap. The adapter that fails gives this output: # sg_readcap --16 /dev/sdb bad field in READ CAPACITY (16) cdb including unsupported service action The adapter that succeeds gives this output: # sg_readcap --16 /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=5860533167 (0x15d50a3af), Number of logical blocks=5860533168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with >2TB HDDs)
This is almost certainly a form of the problem reported in "AS2105-based enclosure size issues with >2TB HDDs". I'm repeating my original message here so linux-usb can see it, and so it can be connected to the older thread. I'll address it in another message. I've appended James Bottomley's response, to avoid creating an additional message. Dale -- Date: Wed, 20 Aug 2014 16:18:00 -0400 From: wor...@alum.mit.edu (Dale R. Worley) To: linux-scsi@vger.kernel.org Subject: Problem with USB-to-SATA adapters I don't know if this is the correct place for this problem, but you people can probably tell me the correct place. I have two "USB to SATA adapter" dongles. In general, they work fine. However I've discovered that one of them handles large (1 TB and above) drives correctly and one does not. In particular, when I use the unsuccessful one, neither fdisk nor gdisk reports the disk size correctly, and the kernel does not read the partition table. More confusingly, both dongles work correctly with large disks on Windows 7 Professional. Both of the following cases are when a 3.0 TB drive is attached. The successful device has the "Diablo" brand. The most interesting messages in the log when I plug in the USB are (the complete message set is appended below): Aug 18 21:56:53 hobgoblin kernel: [ 294.229462] usb 2-1.3: New USB device found, idVendor=152d, idProduct=2338 Aug 18 21:56:53 hobgoblin kernel: [ 294.229475] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Aug 18 21:56:53 hobgoblin kernel: [ 294.229482] usb 2-1.3: Product: USB to ATA/ATAPI bridge Aug 18 21:56:53 hobgoblin kernel: [ 294.229488] usb 2-1.3: Manufacturer: JMicron Aug 18 21:56:53 hobgoblin kernel: [ 294.229495] usb 2-1.3: SerialNumber: 01D91CC4 Aug 18 21:56:54 hobgoblin kernel: [ 295.236576] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.236955] sd 7:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) The unsuccessful device has the "Ez-Connect" brand. The most interesting messages in the log when I plug in the USB are (the complete message set is appended below): Aug 18 21:54:06 hobgoblin kernel: [ 127.674374] usb 2-2: new high-speed USB device number 4 using ehci-pci Aug 18 21:54:06 hobgoblin kernel: [ 127.791128] usb 2-2: New USB device found, idVendor=05e3, idProduct=0718 Aug 18 21:54:06 hobgoblin kernel: [ 127.791135] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=2 Aug 18 21:54:06 hobgoblin kernel: [ 127.791138] usb 2-2: Product: USB Storage Aug 18 21:54:06 hobgoblin kernel: [ 127.791142] usb 2-2: SerialNumber: 0033 Aug 18 21:54:07 hobgoblin kernel: [ 128.847269] sd 6:0:0:0: [sdb] 1565565872 512-byte logical blocks: (801 GB/746 GiB) Dale -- For the Diablo adapter: Aug 18 21:56:53 hobgoblin kernel: [ 294.153343] usb 2-1.3: new high-speed USB device number 5 using ehci-pci Aug 18 21:56:53 hobgoblin kernel: [ 294.229462] usb 2-1.3: New USB device found, idVendor=152d, idProduct=2338 Aug 18 21:56:53 hobgoblin kernel: [ 294.229475] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Aug 18 21:56:53 hobgoblin kernel: [ 294.229482] usb 2-1.3: Product: USB to ATA/ATAPI bridge Aug 18 21:56:53 hobgoblin kernel: [ 294.229488] usb 2-1.3: Manufacturer: JMicron Aug 18 21:56:53 hobgoblin kernel: [ 294.229495] usb 2-1.3: SerialNumber: 01D91CC4 Aug 18 21:56:53 hobgoblin kernel: [ 294.231159] usb-storage 2-1.3:1.0: USB Mass Storage device detected Aug 18 21:56:53 hobgoblin kernel: [ 294.233951] scsi7 : usb-storage 2-1.3:1.0 Aug 18 21:56:53 hobgoblin mtp-probe: checking bus 2, device 5: "/sys/devices/pci:00/:00:1d.7/usb2/2-1/2-1.3" Aug 18 21:56:53 hobgoblin mtp-probe: bus: 2, device: 5 was not an MTP device Aug 18 21:56:54 hobgoblin kernel: [ 295.235735] scsi 7:0:0:0: Direct-Access WDC WD30 EZRX-00SPEB0 PQ: 0 ANSI: 5 Aug 18 21:56:54 hobgoblin kernel: [ 295.236209] sd 7:0:0:0: Attached scsi generic sg2 type 0 Aug 18 21:56:54 hobgoblin kernel: [ 295.236576] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.236955] sd 7:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) Aug 18 21:56:54 hobgoblin kernel: [ 295.237957] sd 7:0:0:0: [sdb] Write Protect is off Aug 18 21:56:54 hobgoblin kernel: [ 295.238957] sd 7:0:0:0: [sdb] No Caching mode page found Aug 18 21:56:54 hobgoblin kernel: [ 295.238962] sd 7:0:0:0: [sdb] Assuming drive cache: write through Aug 18 21:56:54 hobgoblin kernel: [ 295.239956] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.242334] sd 7:0:0:0: [sdb] No Caching mode page found Aug 18 21:56:54 hobgoblin kernel: [
Problem with USB-to-SATA adapters
I don't know if this is the correct place for this problem, but you people can probably tell me the correct place. I have two "USB to SATA adapter" dongles. In general, they work fine. However I've discovered that one of them handles large (1 TB and above) drives correctly and one does not. In particular, when I use the unsuccessful one, neither fdisk nor gdisk reports the disk size correctly, and the kernel does not read the partition table. More confusingly, both dongles work correctly with large disks on Windows 7 Professional. Both of the following cases are when a 3.0 TB drive is attached. The successful device has the "Diablo" brand. The most interesting messages in the log when I plug in the USB are (the complete message set is appended below): Aug 18 21:56:53 hobgoblin kernel: [ 294.229462] usb 2-1.3: New USB device found, idVendor=152d, idProduct=2338 Aug 18 21:56:53 hobgoblin kernel: [ 294.229475] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Aug 18 21:56:53 hobgoblin kernel: [ 294.229482] usb 2-1.3: Product: USB to ATA/ATAPI bridge Aug 18 21:56:53 hobgoblin kernel: [ 294.229488] usb 2-1.3: Manufacturer: JMicron Aug 18 21:56:53 hobgoblin kernel: [ 294.229495] usb 2-1.3: SerialNumber: 01D91CC4 Aug 18 21:56:54 hobgoblin kernel: [ 295.236576] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.236955] sd 7:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) The unsuccessful device has the "Ez-Connect" brand. The most interesting messages in the log when I plug in the USB are (the complete message set is appended below): Aug 18 21:54:06 hobgoblin kernel: [ 127.674374] usb 2-2: new high-speed USB device number 4 using ehci-pci Aug 18 21:54:06 hobgoblin kernel: [ 127.791128] usb 2-2: New USB device found, idVendor=05e3, idProduct=0718 Aug 18 21:54:06 hobgoblin kernel: [ 127.791135] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=2 Aug 18 21:54:06 hobgoblin kernel: [ 127.791138] usb 2-2: Product: USB Storage Aug 18 21:54:06 hobgoblin kernel: [ 127.791142] usb 2-2: SerialNumber: 0033 Aug 18 21:54:07 hobgoblin kernel: [ 128.847269] sd 6:0:0:0: [sdb] 1565565872 512-byte logical blocks: (801 GB/746 GiB) Dale -- For the Diablo adapter: Aug 18 21:56:53 hobgoblin kernel: [ 294.153343] usb 2-1.3: new high-speed USB device number 5 using ehci-pci Aug 18 21:56:53 hobgoblin kernel: [ 294.229462] usb 2-1.3: New USB device found, idVendor=152d, idProduct=2338 Aug 18 21:56:53 hobgoblin kernel: [ 294.229475] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Aug 18 21:56:53 hobgoblin kernel: [ 294.229482] usb 2-1.3: Product: USB to ATA/ATAPI bridge Aug 18 21:56:53 hobgoblin kernel: [ 294.229488] usb 2-1.3: Manufacturer: JMicron Aug 18 21:56:53 hobgoblin kernel: [ 294.229495] usb 2-1.3: SerialNumber: 01D91CC4 Aug 18 21:56:53 hobgoblin kernel: [ 294.231159] usb-storage 2-1.3:1.0: USB Mass Storage device detected Aug 18 21:56:53 hobgoblin kernel: [ 294.233951] scsi7 : usb-storage 2-1.3:1.0 Aug 18 21:56:53 hobgoblin mtp-probe: checking bus 2, device 5: "/sys/devices/pci:00/:00:1d.7/usb2/2-1/2-1.3" Aug 18 21:56:53 hobgoblin mtp-probe: bus: 2, device: 5 was not an MTP device Aug 18 21:56:54 hobgoblin kernel: [ 295.235735] scsi 7:0:0:0: Direct-Access WDC WD30 EZRX-00SPEB0 PQ: 0 ANSI: 5 Aug 18 21:56:54 hobgoblin kernel: [ 295.236209] sd 7:0:0:0: Attached scsi generic sg2 type 0 Aug 18 21:56:54 hobgoblin kernel: [ 295.236576] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.236955] sd 7:0:0:0: [sdb] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB) Aug 18 21:56:54 hobgoblin kernel: [ 295.237957] sd 7:0:0:0: [sdb] Write Protect is off Aug 18 21:56:54 hobgoblin kernel: [ 295.238957] sd 7:0:0:0: [sdb] No Caching mode page found Aug 18 21:56:54 hobgoblin kernel: [ 295.238962] sd 7:0:0:0: [sdb] Assuming drive cache: write through Aug 18 21:56:54 hobgoblin kernel: [ 295.239956] sd 7:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Aug 18 21:56:54 hobgoblin kernel: [ 295.242334] sd 7:0:0:0: [sdb] No Caching mode page found Aug 18 21:56:54 hobgoblin kernel: [ 295.242339] sd 7:0:0:0: [sdb] Assuming drive cache: write through Aug 18 21:56:54 hobgoblin kernel: [ 295.305631] GPT:Primary header thinks Alt. header is not at the end of the disk. Aug 18 21:56:54 hobgoblin kernel: [ 295.305638] GPT:1565565871 != 5860533167 Aug 18 21:56:54 hobgoblin kernel: [ 295.305639] GPT:Alternate GPT header not at the end of the disk. Aug 18 21:56:54 hobgoblin kernel: [ 295.305640] GPT:1565565871 != 5860533167 Aug 18 21:56:54 hobgoblin kernel: [ 295.305642] GPT: Use GNU Parted to correct GPT errors. Aug 18 21:56:54 hobgoblin kernel: [ 295.305653] sdb: sdb1 sdb2 sdb3 sd
Re: Write cache and surface error behaviour
> From: joystick > > I don't really understand this disk cache thing. > Suppose a disk with write cache enabled of writeback type: Linux > receives a write completed notification (a message from the disk) when > the data has reached the cache of the disk. Correct? At that point it is > not considered an in-flight I/O anymore. Correct? > So what happens when the disk tries to write it to the platter and > discovers that there is a media error on that sector? (suppose > relocation does not happen ; maybe sectors exhausted) > Does Linux receive the write error upon the next flush it issues? So the > error is related to the flush? And what happens if Linux never issues > such flush? Thinking about this some more, there's no particular reason for the kernel to use write-back caching in the disk, since the kernel itself maintains a write-back cache. So the kernel can be quite patient about when the disk writes the block to the platters. Given all the complexities of coordinating with a disk that is doing write-back caching, it seems like it would be easier for the kernel to tell the disk to write-through, that is, don't notify the kernel that the write is done until the data is actually on the platter. Most of the time, the kernel can be patient about writing; the only time the kernel has to care is when an application forces synchronization on the disk I/O subsystem. (I vaguely recall this is done only on close() or fsync().) And when that happens, the kernel has to know the data is on the platter. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Write cache and surface error behaviour
> From: joystick > > I don't really understand this disk cache thing. > Suppose a disk with write cache enabled of writeback type: Linux > receives a write completed notification (a message from the disk) when > the data has reached the cache of the disk. Correct? At that point it is > not considered an in-flight I/O anymore. Correct? > So what happens when the disk tries to write it to the platter and > discovers that there is a media error on that sector? (suppose > relocation does not happen ; maybe sectors exhausted) > Does Linux receive the write error upon the next flush it issues? So the > error is related to the flush? And what happens if Linux never issues > such flush? I'm no expert... But modern disks play a lot of games beneath the covers, including patching around bad blocks. So in most cases, if the first write shows a media error, the controller will assign a replacement sector and write the data there. Of course the risks you discuss still exist. My guess is that if people are really worried about their data, they don't use write-back caching. I notice that the startup messages of my system talk of "writethrough" caching, which (IIRC) means that the kernel isn't told that the write is complete until the controller can guarantee the data is in non-volatile memory. In the end, the biggest risk is that the entire disk will suddenly become unreadable. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debug flag parameter for SCSI tape driver
Are ANSI-formatted tapes used on Linux? That is, tapes that contain multiple files and use the the ANSI (= ECMA-13) tape labels. My uderstanding is that a lot of the modern cartridge tapes record only fixed-length blocks and/or that is how they are always used these days. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: add debug flag parameter for SCSI tape driver
This thread leads me to ask: Do people use ANSI-formatted tapes any more? That is, tape volumes with miltiple files, header and trailer labels, etc.? Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Scst-devel] OSS target - VMware SCSI reservation bug conformity.
> From: "Dr. Greg Wettstein" > If there is an issue it would seem to be in the best interests of > those of us committed to open-source storage solutions to understand > and protect ourselves from the situation. There is a third saying > which is important as well: If the question is a legitimate question of interpretation, then the better course is probably "be liberal in what you receive and be conservative in what you transmit". Practically speaking, I remember the story of US Robotics modems. I'm told they captured the market for server modems in the days of dialup services by testing their modems against every make of modem on the market and tweaking its behavior so that it could successfully interwork with basically any modem the consumer purchased, no matter how crappy. This level of reliability was very valuable to the operators of online services. Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Writing session to CD does not update some important cached information.
(This is based on the bug report https://bugzilla.redhat.com/show_bug.cgi?id=918200) When I repartition a disk, when I exit the partitioning tool, it has some method of ordering the kernel to re-read the partition table. Thus, after repartitioning, the partitions I've created/changed are available for use. But when I burn a CD, when the CD-burning tool is done, it does not seem to be able to tell the kernel about the data track that now exists. (Or so the people at bugzilla.redhat.com say.) To gain access to the new track, the CD has to be ejected and reloaded. It seems to me that this is a deficiency that shouldn't be too hard to fix. Thanks for any attention you can give this! Dale -- Here is a detailed example of the problem: The issue is still seen with kernel 3.13.5-101 in Fedora 19. Here is an example: # # Determine version information. # uname -a Linux hobgoblin.ariadne.com 3.13.5-101.fc19.x86_64 #1 SMP Tue Feb 25 21:25:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release Fedora release 19 (Schrödinger’s Cat) # rpm -qa | grep cdr libcdr-0.0.14-1.fc19.x86_64 cdrdao-1.2.3-19.fc19.x86_64 # # Verify that the file contains a valid ISO filesystem. # mount -o loop ~worley/temp/time-warp-iso /mnt/temp mount: /dev/loop0 is write-protected, mounting read-only # ls /mnt/temp COMMIT_EDITMSG ORIG_HEAD config~ index objects refs FETCH_HEAD branches description info packed-refs HEADconfig hookslogs qgit_cache.dat # umount /mnt/temp # # Burn the filesystem onto a new CD-R. # wodim dev=/dev/sr0 -multi speed=32 fs=32m -v -data ~worley/temp/time-warp-iso wodim: No write mode specified. wodim: Assuming -tao mode. wodim: Future versions of wodim may have different drive dependent defaults. TOC Type: 1 = CD-ROM scsidev: '/dev/sr0' devname: '/dev/sr0' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Wodim version: 1.1.11 SCSI buffer size: 64512 Device type: Removable CD-ROM Version: 5 Response Format: 2 Capabilities : Vendor_info: 'TSSTcorp' Identification : 'DVD+-RW TS-U633A' Revision : 'D300' Device seems to be: Generic mmc2 DVD-R/DVD-RW. [...] Track 01: 625 of 625 MB written (fifo 100%) [buf 100%] 25.2x. Track 01: Total bytes read/written: 656142336/656142336 (320382 sectors). Writing time: 255.813s Average write speed 17.1x. Min drive buffer fill was 99% Fixating... Fixating time: 43.895s BURN-Free was never needed. wodim: fifo had 10335 puts and 10335 gets. wodim: fifo was 0 times empty and 9573 times full, min fill was 97%. # # Attempt to mount the CD-R immediately after burning it. # mount /dev/sr0 /mnt/temp mount: /dev/sr0 is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. # dmesg | tail [99045.625479] i801_smbus :00:1f.3: using default PCI settings [99045.649439] dell_wmi: Received unknown WMI event (0x11) [100784.941616] loop: module loaded [100785.165164] ISO 9660 Extensions: Microsoft Joliet Level 3 [100785.222074] ISO 9660 Extensions: RRIP_1991A [100785.07] SELinux: initialized (dev loop0, type iso9660), uses genfs_contexts [100931.369609] fuse init (API version 7.22) [100931.711371] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts [100932.052892] SELinux: initialized (dev fusectl, type fusectl), uses genfs_contexts [101215.067563] isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 # # Eject and reload the CD-R and then try to mount it. # eject /dev/sr0 # mount /dev/sr0 /mnt/temp mount: /dev/sr0 is write-protected, mounting read-only # ll /mnt/temp total 2493 -r--r--r--. 1 root root 34 Mar 8 03:45 COMMIT_EDITMSG -r--r--r--. 1 root root 87 May 27 2013 FETCH_HEAD -r--r--r--. 1 root root 26 Jun 12 2013 HEAD -r--r--r--. 1 root root 41 Mar 8 02:45 ORIG_HEAD dr-xr-xr-x. 2 root root2048 May 11 2013 branches -r--r--r--. 1 root root 234 Mar 6 12:55 config -r--r--r--. 1 root root 233 Feb 26 14:34 config~ -r--r--r--. 1 root root 73 May 11 2013 description dr-xr-xr-x. 2 root root2048 May 11 2013 hooks -r--r--r--. 1 root root 2350328 Mar 8 02:45 index dr-xr-xr-x. 2 root root2048 Mar 8 02:54 info dr-xr-xr-x. 3 root root2048 May 22 2013 logs dr-xr-xr-x. 4 root root2048 Mar 8 02:54 objects -r--r--r--. 1 root root 302 Mar 8 02:45 packed-refs -r--r--r--. 1 root root 185477 Jul 31 2013 qgit_cache.dat dr-xr-xr-x. 6 root root2048 Nov 15 11:52 refs # -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
