On Mon, Sep 26, 2016 at 09:25:11AM -0700, Christoph Hellwig wrote:
> On Mon, Sep 26, 2016 at 12:19:26PM -0400, Theodore Ts'o wrote:
> > Is this a problem with the hardware, or with the UAS driver?
>
> UAS is just SCSI transport, and doesn't touch the content of command,
> so it
Hi, I have a Samsung 850 Pro SSD which is currently in a USB 3.0 / UAS
external enclosure. The Samsung SSD uses a 512 byte physical and logical
sector size, and when it is accessed via the usb-storage device, this
is what I get.
In a vain hope that I could get discard working, I built a kernel
On Wed, Jun 01, 2016 at 03:17:14PM +0200, Gernot Hillier wrote:
> I repeated the discussed tests and found comparable results on this machine:
>
> - 3 seconds dpkg install time on ext3 vs. 80 seconds for ext4
> on same partition for same package
> - 40 ms for fallocate+write+sync_file_range for
On Wed, Apr 06, 2016 at 11:41:49AM -0700, Greg KH wrote:
> > > > Is this Nick Krause? An email reply that Martin forwarded but the
> > > > list didn't pick up (because it had a html part) suggests this.
> > > > What you're doing is what got you banned from LKML the last time:
> > > > sending
On Sat, Aug 15, 2015 at 10:19:02AM +0200, Christoph Hellwig wrote:
sorry for the delay - I saw the mail Jan Cc'ed me on yesterday. After
my changes it should not go away and I had tested the original eject
test that it indeed didn't. Either I forgot a case, or the major
writeback Tejun did
On Fri, Aug 14, 2015 at 11:02:14AM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=101011
I can also confirm that this bug is present in latest stable kernel (4.1.5)
and
reverting commit from comment 6 seems to fix it.
Christoph,
I've since
On Fri, Dec 05, 2014 at 10:58:09PM +, Elliott, Robert (Server Storage)
wrote:
I have a Crucial_CT256MX1 (i.e. MX100) and it does reliably zero.
make me concerned about this whitelist approach.
I think you need a manufacturer assertion that this is indeed
the design intent; you cannot
On Fri, Nov 07, 2014 at 10:42:24AM -0500, Martin K. Petersen wrote:
Christoph == Christoph Hellwig h...@infradead.org writes:
Christoph I'm not a fan of adding another function here and would
Christoph prefer a flag, but it looks correct,
That was my original approach too but I didn't
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
On Mon, Jun 23, 2014 at 08:44:40AM +0100, Al Viro wrote:
OK, here it is, hopefully with sufficient comments:
The comments look really good. I assume you'll get this to
Linus in time for 3.16-rc3?
Many thanks!!
- Ted
--
To unsubscribe from this list:
On Sun, Jun 22, 2014 at 02:00:32AM +0100, Al Viro wrote:
PS: I agree that it's worth careful commenting, obviously, but
before sending it to Linus (*with* comments) I want to get a
confirmation that this one-liner actually fixes what Ted is seeing.
I have reproduced it here, and that change
On Sat, Jun 21, 2014 at 06:53:07AM +0100, Al Viro wrote:
ed include/linux/uio.h EOF
/iov_iter_truncate/s/size_t/u64/
w
q
EOF
Could you check if that fixes the sucker?
The following patch (attached at the end) appears to fix the problem,
but looking at uio.h, I'm completely confused
On Fri, Jun 20, 2014 at 08:38:20AM +1000, Dave Chinner wrote:
Short reads are more likely a bug in all the iovec iterator stuff
that got merged in from the vfs tree. ISTR a 32 bit-only bug in that
stuff go past in to do with not being able to partition a 32GB block
dev on a 32 bit system due
While trying to bisect some problems which were introduced sometime
between 3.15 and 3.16-rc1 (specifically, (1) reads to a block device
at offset 262144 * 4k are failing with a short read, and (2) block
device reads are sometimes causing the entire kernel to hang), the
following BUG got hit.
[
On Thu, Jun 19, 2014 at 08:59:26AM -0700, Jens Axboe wrote:
I believe you already reported this issue a while back, and it should be
fixed by commit cb96a42c in the kernel.
Ah yes, I had forgotten. Thanks for the reminder!
The other issue, not sure, not a lot of detail. It may be fixed by
On Thu, Jun 19, 2014 at 12:08:01PM -0400, Theodore Ts'o wrote:
The other issue, not sure, not a lot of detail. It may be fixed by the pull
request I sent out yesterday. You can try pulling in:
git://git.kernel.dk/linux-block.git for-linus
Thanks, I'll give that a try.
I tried merging
-by: Theodore Ts'o ty...@mit.edu
--
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
On Fri, Apr 25, 2014 at 12:36:10AM -0700, Christoph Hellwig wrote:
But this also brings up an interesting question: blk-mq currently
does not set QUEUE_FLAG_ADD_RANDOM in the default queue flags, so
simply converting a driver to blk-mq will mean it stops contributing
to the random pool. Do
On Tue, Feb 11, 2014 at 09:57:40AM -0200, Carlos Maiolino wrote:
Thanks for clarification, and, this just enforce my concept that ZBC protocol
should be integrated in the generic block layer not make it device-mapper
dependent. So, make this available to any device that supports it with or
On Thu, Jan 23, 2014 at 07:35:58PM +1100, Dave Chinner wrote:
I expect it would be relatively simple to get large blocksizes working
on powerpc with 64k PAGE_SIZE. So before diving in and doing huge
amounts of work, perhaps someone can do a proof-of-concept on powerpc
(or ia64) with
On Wed, Jan 22, 2014 at 06:46:11PM -0800, David Lang wrote:
It's extremely unlikely that drive manufacturers will produce drives
that won't work with any existing OS, so they are going to support
smaller writes in firmware. If they don't, they won't be able to
sell their drives to anyone
On Wed, Jun 19, 2013 at 12:15:53PM -0700, Joe Perches wrote:
Don't emit OOM warnings when k.alloc calls fail when
there there is a v.alloc immediately afterwards.
Signed-off-by: Joe Perches j...@perches.com
For fs/ext4/super.c:
Acked-by: Theodore Ts'o ty...@mit.edu
Paolo,
I'll probably regret butting my head into this, but it might be
helpful if you talk about your particular use case which is driving
your desire to make these changes. For example, what do you think the
SG_IO whitelist _should_ be used, and why should it be made more
general? What's the
On Wed, May 22, 2013 at 07:00:14PM +0200, Paolo Bonzini wrote:
You have hardware providers selling cloud services that want to run
their own custom backup services from within a VM, which entails having
vendor-specific commands run from within a VM. Or you have people that
run clusters that
On Wed, May 22, 2013 at 09:37:54PM +0200, Paolo Bonzini wrote:
If it's not theoretical, how does the cloud service control who has
access to the CD burner, and how are the disks loaded into the CD
burner?
CD burning would be used in a VM that runs on your local workstation, so
the VM
On Sun, Nov 11, 2012 at 10:15:02AM -0500, Bradley M. Kuhn wrote:
Andy's initial email ended with the request: Please explain. Thus,
Andy's email seemed designed to seek facts, which I think is a
reasonable and good thing to do here. Meanwhile, the facts *still*
aren't clear here yet.
...
On Sun, Nov 11, 2012 at 09:34:16AM +, James Bottomley wrote:
Anybody who does enforcement will tell you that you begin with first
hand proof of a violation. That means obtain the product and make sure
it's been modified and that a request for corresponding source fails.
In this case,
27 matches
Mail list logo
