On Sat, May 31, 2014 at 12:34:12PM -0700, H. Peter Anvin wrote:
> Typically they are using 64-bit signed seconds.
Okay, that is what I wanted to know.
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
Mor
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
> On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
> >
> > Why are some of the time stamp expiration dates marked as "never"?
>
> It's an approximation:
Also, the term "never" might mean using arbitrarily long integers
as in A
Typically they are using 64-bit signed seconds.
On May 31, 2014 11:22:37 AM PDT, Richard Cochran
wrote:
>On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
>>
>> It's an approximation:
>
>(Approximately never ;)
>
>> with 64-bit timestamps, you can represent close to 300 billion
>>
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
>
> It's an approximation:
(Approximately never ;)
> with 64-bit timestamps, you can represent close to 300 billion
> years, which is way past the time that our planet can sustain
> life of any form[1].
Did you mean mean 64 bits wor
On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
> On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
> >
> > I picked this because it is a fairly isolated problem, as the
> > inode time stamps are rarely assigned to any other time values.
> > As a byproduct of this work, I docu
On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
>
> I picked this because it is a fairly isolated problem, as the
> inode time stamps are rarely assigned to any other time values.
> As a byproduct of this work, I documented for each of the file
> systems we support how long the on-d
Hi Arnd,
On Fri, 2014-05-30 at 22:01 +0200, Arnd Bergmann wrote:
[snip]
>
> Arnd Bergmann (32):
> fs: introduce new 'struct inode_time'
> uapi: add struct __kernel_timespec{32,64}
> fs: introduce sys_utimens64at
> fs: introduce sys_newfstat64/sys_newfstatat64
> arch: hook up new stat a
This patch remove variables that are initialized with a constant,
are never updated, and are only used as parameter of return.
Return the constant instead of using a variable.
Verified by compilation only.
The coccinelle script that find and fixes this issue is:
//
@@
type T;
constant C;
identif
This patch remove variables that are initialized with a constant,
are never updated, and are only used as parameter of return.
Return the constant instead of using a variable.
Verified by compilation only.
The coccinelle script that find and fixes this issue is:
//
@@
type T;
constant C;
identif
On Sat, May 31, 2014 at 05:13:11AM +, Eddie Wai wrote:
>
>
> On May 30, 2014, at 7:48 PM, "Neil Horman" wrote:
>
> > On Fri, May 30, 2014 at 02:59:43PM -0700, Eddie Wai wrote:
> >> Thanks for fixing this. The patch generally looks good, but I do have a
> >> few comments.
> >>
> >> On Fri,
Older HBAs are only capable of supporting 16-bit LUNs,
so we need to make sure to adjust max_lun accordingly.
Signed-off-by: Hannes Reinecke
Acked-by: Chad Dupuis
Reviewed-by: Christoph Hellwig
Reviewed-by: Ewan Milne
---
drivers/scsi/qla2xxx/qla_os.c | 7 ++-
1 file changed, 6 insertions
Obsolete; either use 'max_lun' if the host supports only a
limited number of LUNs or BLIST_NOLUN if the target has
problems addressing more than one LUN.
Signed-off-by: Hannes Reinecke
Reviewed-by: Christoph Hellwig
Reviewed-by: Ewan Milne
---
Documentation/scsi/tmscsim.txt | 2 --
drivers/sc
scsilun_to_int() has an error which prevents it from generating
correct LUN numbers for 64bit values.
Also we should remove the misleading comment about portions of
the LUN being ignored; the initiator should treat the LUN as
an opaque value.
And, finally, the example given should use the correct
p
Hi all,
this patchset updates the SCSI stack to support full 64-bit LUNs.
The first patch is a simple fix; the next patch updates
the sequential scan logic to be compliant with SPC.
The third patch addresses a firmware issue with earlier
qla2xxx HBAs.
The next two patches update the SCSI stack and
Now that we're using 64-bit LUNs internally we need to increase
the size of max_luns to 64 bits, too.
Signed-off-by: Hannes Reinecke
Reviewed-by: Christoph Hellwig
Reviewed-by: Ewan Milne
---
drivers/message/i2o/i2o_scsi.c | 2 +-
drivers/scsi/advansys.c | 2 +-
drivers/sc
Sequential scan for more than 256 LUNs is very fragile as
LUNs might not be numbered sequentially after that point.
SAM revisions later than SCSI-3 impose a structure on
LUNs larger than 256, making LUN numbers between 256
and 16384 illegal.
SCSI-3, however allows for plain 64-bit numbers with
no
16 matches
Mail list logo
