Re: DIOCGDISCARDINFO and DIOCDISCARD
Hello, On Wed, 23 Oct 2013 18:55:35 +0200 Matthias Drochner m.droch...@fz-juelich.de wrote: On Wed, 23 Oct 2013 03:07:59 -0400 Michael macal...@netbsd.org wrote: I use mine with PATA adaptors: wd0 at atabus0 drive 0 wd0: SanDisk SDCFH-008G It it identified as ATAPI by atactl identify? If yes, does the patch help? If it identifies as CF-ATA, one could add support for the Erase, and possibly Write Sectors without Erase to the wd driver (or possibly an autoconf attachment, to avoid bloat). This is the PowerBook ( with the CF card replacing the internal harddisk ) with your patches applied: wd0 at atabus0 drive 0 wd0: SanDisk SDCFH-008G wd0: drive supports 1-sector PIO transfers, LBA addressing wd0: 7641 MB, 15525 cyl, 16 head, 63 sec, 512 bytes/sect x 15649200 sectors wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66) wd0(wdc0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66) (using DMA) # atactl wd0 identify Model: SanDisk SDCFH-008G, Rev: HDX 5.07, Serial #: DPZ011210203707 Device type: CF-ATA Capacity 8012 Mbytes, 15649200 sectors, 512 bytes/sector Cylinders: 15525, heads: 16, sec/track: 63 Device capabilities: DMA LBA ATA standby timer values Device supports following standards: ATA-4 Command set support: NOP command (enabled) READ BUFFER command (enabled) WRITE BUFFER command (enabled) Write cache (disabled) FLUSH CACHE EXT command (disabled) FLUSH CACHE command (disabled) Advanced Power Management feature set (disabled) CFA feature set (enabled) I didn't see any negative side effects ( or for that matter, any side effects other than the changed atactl output ) on the powerbook or the Blade. have fun Michael
Re: DIOCGDISCARDINFO and DIOCDISCARD
On Tue, 22 Oct 2013 22:35:59 +0200 Matthias Drochner m.droch...@fz-juelich.de wrote: On Fri, 11 Oct 2013 10:31:39 -0400 Michael macal...@netbsd.org wrote: Something related - how difficult would it be to support something TRIM-ish on CompactFlash? Not that I have the faintest clue about ATA in general, let alone the CF-specific extensions... The CF part should be easy to do. To be useful in practice, it would also be necessary to add calls to it from msdosfs. This code is a mess. Also, common USB card readers don't support the commands needed AFAIK. I use mine with PATA adaptors: wd0 at atabus0 drive 0 wd0: SanDisk SDCFH-008G wd0: drive supports 1-sector PIO transfers, LBA48 addressing wd0: 7629 MB, 15501 cyl, 16 head, 63 sec, 512 bytes/sect x 15625216 sectors wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 4 (Ultra/66) wd0(aceride0:0:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA) ( that's what my Sun Blade 2500 boots from so I could get rid of loud and hot SCSI disks, got another one in a PowerBook where it replaces the harddisk ) So, there's no msdosfs anywhere. I'm not too concerned about the one in the Blade since it doesn't get a lot of writes ( just kernel updates and occasional updates of the rescue filesystem - everythig else is on a SATA disk ) but the PowerBook is a different story. While we are here... I've found some problems with CF cards when I plugged them into a PCMCIA slot. First was that it was not correctly identified by atactl. The other that the machine crashed on shutdown if the card's filesystem was not mounted, so that the slot was powered down. If you have your CF cards connected in a similar way (i.e. not translated into an sd SCSI device), could you try the appended patch and see that it does no damage? Sorry, I have any PCMCIA, CardBus or USB to CF adaptors. have fun Michael
Re: DIOCGDISCARDINFO and DIOCDISCARD
On Wed, 23 Oct 2013 03:07:59 -0400 Michael macal...@netbsd.org wrote: I use mine with PATA adaptors: wd0 at atabus0 drive 0 wd0: SanDisk SDCFH-008G It it identified as ATAPI by atactl identify? If yes, does the patch help? If it identifies as CF-ATA, one could add support for the Erase, and possibly Write Sectors without Erase to the wd driver (or possibly an autoconf attachment, to avoid bloat). There is also some true IDE mode mentioned in the spec, which seems to mean that drive looks exactly like a conventional disk. It is switched on by pin strapping, so it depends on the adapter. best regards Matthias Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
Re: DIOCGDISCARDINFO and DIOCDISCARD
On Fri, 11 Oct 2013 10:31:39 -0400
Michael macal...@netbsd.org wrote:
Something related - how difficult would it be to support something
TRIM-ish on CompactFlash? Not that I have the faintest clue about ATA
in general, let alone the CF-specific extensions...
The CF part should be easy to do. To be useful in practice, it would
also be necessary to add calls to it from msdosfs. This code is
a mess. Also, common USB card readers don't support the commands
needed AFAIK.
While we are here... I've found some problems with CF cards
when I plugged them into a PCMCIA slot. First was that it was not
correctly identified by atactl. The other that the machine crashed
on shutdown if the card's filesystem was not mounted, so that
the slot was powered down.
If you have your CF cards connected in a similar way (i.e. not
translated into an sd SCSI device), could you try the appended
patch and see that it does no damage?
best regards
Matthias
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
# HG changeset patch
# Parent 24bbe2c07df0865de34a29b0279a2cbb52bbddc4
diff -r 24bbe2c07df0 distrib/utils/sysinst/disks.c
--- a/distrib/utils/sysinst/disks.c Tue Aug 13 12:24:16 2013 +0200
+++ b/distrib/utils/sysinst/disks.c Tue Aug 13 15:05:05 2013 +0200
@@ -259,7 +259,8 @@
* Mitsumi ATAPI devices
*/
- if (!((inqbuf-atap_config WDC_CFG_ATAPI_MASK) == WDC_CFG_ATAPI
+ if (!(inqbuf-atap_config != WDC_CFG_CFA_MAGIC
+ (inqbuf-atap_config WDC_CFG_ATAPI)
((inqbuf-atap_model[0] == 'N'
inqbuf-atap_model[1] == 'E') ||
(inqbuf-atap_model[0] == 'F'
diff -r 24bbe2c07df0 sbin/atactl/atactl.c
--- a/sbin/atactl/atactl.c Tue Aug 13 12:24:16 2013 +0200
+++ b/sbin/atactl/atactl.c Tue Aug 13 15:05:05 2013 +0200
@@ -947,7 +947,8 @@
* Mitsumi ATAPI devices
*/
- if (!((inqbuf-atap_config WDC_CFG_ATAPI_MASK) == WDC_CFG_ATAPI
+ if (!(inqbuf-atap_config != WDC_CFG_CFA_MAGIC
+ (inqbuf-atap_config WDC_CFG_ATAPI)
((inqbuf-atap_model[0] == 'N'
inqbuf-atap_model[1] == 'E') ||
(inqbuf-atap_model[0] == 'F'
@@ -980,9 +981,13 @@
((uint64_t)inqbuf-atap_wwn[2] 16) |
((uint64_t)inqbuf-atap_wwn[3] 0));
- printf(Device type: %s, %s\n, inqbuf-atap_config WDC_CFG_ATAPI ?
- ATAPI : ATA, inqbuf-atap_config ATA_CFG_FIXED ? fixed :
- removable);
+ printf(Device type: %s,
+ inqbuf-atap_config == WDC_CFG_CFA_MAGIC ? CF-ATA :
+(inqbuf-atap_config WDC_CFG_ATAPI ? ATAPI : ATA));
+ if (inqbuf-atap_config != WDC_CFG_CFA_MAGIC)
+ printf(, %s,
+inqbuf-atap_config ATA_CFG_FIXED ? fixed : removable);
+ printf(\n);
compute_capacity(inqbuf, capacity, sectors, secsize);
diff -r 24bbe2c07df0 sys/dev/ata/atareg.h
--- a/sys/dev/ata/atareg.h Tue Aug 13 12:24:16 2013 +0200
+++ b/sys/dev/ata/atareg.h Tue Aug 13 15:05:05 2013 +0200
@@ -284,7 +284,7 @@
struct ataparams {
/* drive info */
uint16_t atap_config;/* 0: general configuration */
-#define WDC_CFG_ATAPI_MASK 0xc000
+#define WDC_CFG_CFA_MAGIC 0x848a
#define WDC_CFG_ATAPI 0x8000
#defineATA_CFG_REMOVABLE 0x0080
#defineATA_CFG_FIXED 0x0040
diff -r 24bbe2c07df0 sys/dev/ata/wd.c
--- a/sys/dev/ata/wd.c Tue Aug 13 12:24:16 2013 +0200
+++ b/sys/dev/ata/wd.c Tue Aug 13 15:05:05 2013 +0200
@@ -408,8 +408,14 @@
{
struct wd_softc *sc = device_private(dv);
+ /* the adapter needs to be enabled */
+ if (sc-atabus-ata_addref(sc-drvp))
+ return true; /* no need to complain */
+
wd_flushcache(sc, AT_WAIT);
wd_standby(sc, AT_WAIT);
+
+ sc-atabus-ata_delref(sc-drvp);
return true;
}
diff -r 24bbe2c07df0 sys/dev/usb/umass_isdata.c
--- a/sys/dev/usb/umass_isdata.cTue Aug 13 12:24:16 2013 +0200
+++ b/sys/dev/usb/umass_isdata.cTue Aug 13 15:05:05 2013 +0200
@@ -546,8 +546,8 @@
* Shuffle string byte order.
* ATAPI Mitsumi and NEC drives don't need this.
*/
-
Re: DIOCGDISCARDINFO and DIOCDISCARD
On Tue, 1 Oct 2013 07:01:51 + David Holland dholland-t...@netbsd.org wrote: On Sat, Jun 15, 2013 at 11:56:55PM +, David Holland wrote: wd TRIM support Something related - how difficult would it be to support something TRIM-ish on CompactFlash? Not that I have the faintest clue about ATA in general, let alone the CF-specific extensions... have fun Michael
Re: DIOCGDISCARDINFO and DIOCDISCARD
On Sat, Jun 15, 2013 at 11:56:55PM +, David Holland wrote: I had almost forgotten about this; but a few months back when I came into contact with the wd TRIM support in current I wanted to change the interface around before it appears in a release. Ok, as of this writing I have preliminary patches for about half of the following: - add a d_discard op to struct bdevsw - add VOP_FALLOCATE and VOP_FDISCARD - implement spec_fdiscard that calls d_discard - add posix_fallocate, fallocate, and fdiscard syscalls that call VOP_FALLOCATE and VOP_FDISCARD - add posix_fallocate, fallocate, and fdiscard to libc - change existing device DIOCDISCARD implementations to d_discard implementations - update the ffs -odiscard code to use the new interface - fix existing discard implementations to not require the caller to check the maximum range that can be discarded at once - remove DIOCGDISCARDPARAMS - remove DIOCDISCARD - implement d_discard on dk, closing PR 47940 - fix PR 47435, where wd's discard lets you zoom off the end of a partition or (I think) even the whole disk - add compat_linux support for linux's native fallocate and linux's posix_fallocate Notes and comments on this: - I hope adding an op to struct bdevsw isn't going to cause a ruckus or open a can of worms. It seems like the right thing to do. However, there are other disk ioctls that I would think probably ought to be first-class bdevsw ops and I'm not sure what the conventional wisdom is. - I'm not adding either fallocate or fdiscard support for regular files to any fs yet; this batch of changes is all plumbing and for access to existing TRIM support. Doing this shouldn't be that hard. - I have defined all the interfaces (including the bdevsw one) to use off_t and byte counts and offsets. I don't think proliferation of DEV_BSIZE is beneficial; plus if everything is bytes it reduces the chance of using the wrong shift macro and messing everything up. For an operation that erases data in a bulk fashion at a low level, I think this is fairly important. - I don't think we should adopt Linux's native fallocate interface. It has the ugly misfeature that discard is, rather than a separate call, an extra flag passed to fallocate -- that is, you delete blocks by allocating. - I haven't decided if our native fallocate and fdiscard interface should expose the Linux option to leave the file size unchanged. (In Linux this allows allocating blocks past EOF, which is wrong on many levels...) If not, our native fallocate will end up the same as posix_fallocate. Another option is to allow this for fdiscard (where it makes more sense) but not fallocate. int fallocate(int fd, off_t pos, off_t len, int keepsize); int fdiscard(int fd, off_t pos, off_t len, int keepsize); or int fallocate(int fd, off_t pos, off_t len); int fdiscard(int fd, off_t pos, off_t len); or int fallocate(int fd, off_t pos, off_t len); int fdiscard(int fd, off_t pos, off_t len, int keepsize); - I think it's ok to have a fallocate that's incompatible with the linux fallocate, as long as we also have posix_fallocate. - The vnode-level interface supports the keep-size option because it's supposed to be able to support the linux fallocate. - Someone(TM) should add discard support to vnd and raidframe, and probably also ld and in a few other places; I might do this afterwards but I'm not (I think) going to do it as part of the main patch set. - This patch set is all interconnected so it looks unlikely that it can be committed incrementally. Thoughts and objections? I'll post a link to the patches when they're more fully baked. -- David A. Holland dholl...@netbsd.org
DIOCGDISCARDINFO and DIOCDISCARD
I had almost forgotten about this; but a few months back when I came into contact with the wd TRIM support in current I wanted to change the interface around before it appears in a release. The current interface is two ioctls: - first you call DIOCGDISCARDINFO; this tells you the maximum number of blocks that can be discarded at once on the current device. - Then you call DIOCDISCARD with a block number and (I think) block count to actually do it. I have the following objections to this interface: 1. The interface doesn't need to and shouldn't expose the hardware limit of how many blocks can be discarded at once; instead, for large discards (which are not the common case) the loop over block ranges should be done in the driver. 2. The interface uses DEV_BSIZE units. Rather than promote the further proliferation of DEV_BSIZE, it should use either byte offsets or the device's own addressable block size. (I think byte offsets are best; making everything byte offsets minimizes the chance of sending in the wrong units.) 3. The interface is ioctl-based. I would like to see VOP_DISCARD for vnodes (which on regular files creates holes) and a corresponding block device op on struct bdevsw. And a syscall for user access to the operation. This would provide access to functionality that's currently lacking; also it will allow discard to work on vnd devices. Thoughts? (we can argue about what to call the syscall; I think there's prior art but can't remember what at the moment) -- David A. Holland dholl...@netbsd.org
Re: DIOCGDISCARDINFO and DIOCDISCARD
On Sat, Jun 15, 2013 at 11:56:55PM +, David Holland wrote: (we can argue about what to call the syscall; I think there's prior art but can't remember what at the moment) fallocate with FALLOC_FL_PUNCH_HOLE on the device node? Joerg
