>>>>> "James" == James Bottomley <James.Bottomley@xxxxxxx> writes: James> Agree entirely for this with UNMAP, since the array will just James> silently discard what it doesn't want. James> Don't necessarily agree with this for WRITE_SAME. From the James> implementations I've read, it sounds like the array will discard James> all sectors within the correct boundary and alignment but it will James> have to write zeros to all sectors outside of the aligned region James> ... this sounds like a performance hit unless we do some James> judicious aligning of the discards. Depends whether the array firmware tracks partial allocation units or not. Some do (and will report allocation units in the block limits VPD because it's a hint to FS/DB allocators). Since all vendors I've talked to treat unmaps (whether UNMAP or WRITE SAME with the UNMAP bit set) asynchronously, I doubt it's a problem. And they all seem to think that the overhead is minimal. They say we can worry about loss of a queue tag, but that we shouldn't worry about processing time on the back end at all. Should the problem arise I vote for doing the alignment correction in the WRITE SAME codepath in sd.c. Potentially backed by some heuristic. That solves the problem of information being lost on the way down due to stacking and whatnot... -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
