Three patches here:
1) Ensure that we align ->map properly
2) v2 of the sbitmap clear cost ammortization. Updated to do a wakeup
check AFTER we're done swapping free/cleared masks. Kept the
separate alignment for ->word, as it is faster in testing.
3) Cost reduction of having to do wait
Bcc:
Subject: [GIT PULL] nvme updates for 4.20
Reply-To:
A relatively boring merge window:
- better AEN tracing (Chaitanya)
- NUMA aware PCIe multipathing (me)
- RDMA workqueue fixes (Sagi)
- better bio usage in the target (Sagi)
- FC rework for target removal (James)
- better multipath
Michael.
Michael Schmitz - 01.07.18, 04:43:
> Am 30.06.18 um 19:49 schrieb Martin Steigerwald:
> > I am really inclined to point some AmigaOS 4 developers to this
> > discussion and just looked for an archive. Unfortunately there does
> > not appear to be a working one. The one mentioned on
> >
FWIW on the other side this appears to be a good source of Amiga software data.
http://amigadev.elowar.com/
{^_^}
On 20180630 19:43, Michael Schmitz wrote:
Martin,
Am 30.06.18 um 19:49 schrieb Martin Steigerwald:
I am really inclined to point some AmigaOS 4 developers to this
discussion and
Martin,
Am 30.06.18 um 19:49 schrieb Martin Steigerwald:
> I am really inclined to point some AmigaOS 4 developers to this
> discussion and just looked for an archive. Unfortunately there does not
> appear to be a working one. The one mentioned on
>
> http://www.linux-m68k.org/mail.html
>
>
Hi Geert,
Am 01.07.2018 um 09:10 schrieb Geert Uytterhoeven:
Hi Michael,
On Fri, Jun 29, 2018 at 11:12 AM Michael Schmitz wrote:
Am 28.06.18 um 01:30 schrieb Geert Uytterhoeven:
On Wed, Jun 27, 2018 at 4:47 AM wrote:
From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
Hi Andreas,
On Fri, Jun 29, 2018 at 3:26 PM Andreas Schwab wrote:
> On Jun 29 2018, Michael Schmitz wrote:
> > Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
> > to use it?
>
> GPT has the concept of a protective MBR which should prevent such errors.
Thanks, good to
Hi Michael,
On Fri, Jun 29, 2018 at 11:12 AM Michael Schmitz wrote:
> Am 28.06.18 um 01:30 schrieb Geert Uytterhoeven:
> > On Wed, Jun 27, 2018 at 4:47 AM wrote:
> >> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
> > ??
> >
> >> The Amiga RDB partition parser module
As software is discovered to be "broken" at it to the appropriate incompatible
list.
Otherwise permanently limit AmigaDOS to 2TB.
{^_^}
On 20180630 02:07, Martin Steigerwald wrote:
jdow - 30.06.18, 08:47:
Let's get everybody:
On 20180629 22:26, Michael Schmitz wrote:
> Joanne,
>
> Am
Get everybody
On 20180630 00:49, Martin Steigerwald wrote:
> Whoa, my summary essay triggered digging even more accurately into that
> matter. For some obscure reason I am even enjoying this. :)
>
> jdow - 30.06.18, 05:56:
>> On 20180629 18:31, Michael Schmitz wrote:> Joanne,
>>
>> > Am
For Linux:
1) Make a change to the Linux RDB parser so that the product of the "CHS" values
goes to at least a 64 bit entity, It may need to go to a 128 bit entity when we
are encoding data in DNA, crystal lattices, or something else super dense. The
parser simply feeds data to the OS. No
jdow - 30.06.18, 08:47:
> Let's get everybody:
>
> On 20180629 22:26, Michael Schmitz wrote:
> > Joanne,
> >
> > Am 30.06.18 um 15:56 schrieb jdow:
> > As far as I can guess from the code, pb_Environment[3] (number
> > of
>
> heads)
>
> > and
Michael. Joanne.
I do think this discussion is slightly getting out of hand… so I suggest
to focus on what its up to the kernel to do and what is not. And to
focus only on what is up to the RDB parser, cause the patch is on
changing that. The RDB parser is not responsible for what any file
Whoa, my summary essay triggered digging even more accurately into that
matter. For some obscure reason I am even enjoying this. :)
jdow - 30.06.18, 05:56:
> On 20180629 18:31, Michael Schmitz wrote:> Joanne,
>
> > Am 30.06.18 um 12:57 schrieb jdow:
> >> On 20180629 17:44, Michael Schmitz
Let's get everybody:
On 20180629 22:26, Michael Schmitz wrote:
> Joanne,
>
>
> Am 30.06.18 um 15:56 schrieb jdow:
>>
> As far as I can guess from the code, pb_Environment[3] (number of
heads)
> and pb_Environment[5] (number of sectors per cylinder) are abitrarily
> chosen so the
Joanne,
Am 30.06.18 um 15:56 schrieb jdow:
>
> >>> As far as I can guess from the code, pb_Environment[3] (number of
> >> heads)
> >>> and pb_Environment[5] (number of sectors per cylinder) are abitrarily
> >>> chosen so the partition size can be expressed as a difference between
> >>>
On 20180629 18:31, Michael Schmitz wrote:> Joanne,
>
>
> Am 30.06.18 um 12:57 schrieb jdow:
>> On 20180629 17:44, Michael Schmitz wrote:
>>
>>> struct PartitionBlock {
>>>__be32 pb_ID;
>>>__be32 pb_SummedLongs;
>>>__s32 pb_ChkSum;
>>>__u32
Joanne,
Am 30.06.18 um 12:57 schrieb jdow:
> On 20180629 17:44, Michael Schmitz wrote:
>
> > struct PartitionBlock {
> > __be32 pb_ID;
> > __be32 pb_SummedLongs;
> > __s32 pb_ChkSum;
> > __u32 pb_HostID;
> > __be32 pb_Next;
> > __u32
On 20180629 17:44, Michael Schmitz wrote:
> struct PartitionBlock {
> __be32 pb_ID;
> __be32 pb_SummedLongs;
> __s32 pb_ChkSum;
> __u32 pb_HostID;
> __be32 pb_Next;
> __u32 pb_Flags;
> __u32 pb_Reserved1[2];
>
On 20180629 16:24, Michael Schmitz wrote:
> Martin,
>
>
...
> The problem that still remains is with unpatched legacy versions. RDB
> does support large enough partitions out of the box, due to C/H/S all
> using u32. We all agree there. The question is with file systems and
Nope, I bothered to
Joanne,
Am 30.06.18 um 11:24 schrieb jdow:
>
> On 20180629 14:45, Martin Steigerwald wrote:
> > Beware: Essay ahead which proofs it to the point that there is no
> > overflow in RDB before 96 bits maximum value of sectors:
>
> Time to go into more detail on RDBs. It isn't as simple as it started
Martin,
Am 30.06.18 um 09:24 schrieb Martin Steigerwald:
> Hi Michael.
>
> Michael Schmitz - 29.06.18, 11:07:
>>> But it's up to the person (which is not Linux) formatting the disk
>>> to
>>> not try to use
>>> it on systems that cannot handle it, and may destroy it.
>>>
> Let me clarify:
On 20180629 14:45, Martin Steigerwald wrote:
> Beware: Essay ahead which proofs it to the point that there is no
> overflow in RDB before 96 bits maximum value of sectors:
Time to go into more detail on RDBs. It isn't as simple as it started to appear.
extract from hardblocks.h RDSK block
Beware: Essay ahead which proofs it to the point that there is no
overflow in RDB before 96 bits maximum value of sectors:
jdow - 29.06.18, 11:32:
> On 20180629 01:42, Michael Schmitz wrote:
> > Hi Geert,
> >
> > Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> Do we really need the
Hi Michael.
Michael Schmitz - 29.06.18, 11:07:
> > But it's up to the person (which is not Linux) formatting the disk
> > to
> > not try to use
> > it on systems that cannot handle it, and may destroy it.
> >
> >>> Let me clarify: what exactly would the kernel option allow? When
> >>> to use
Hi,
Geert Uytterhoeven - 29.06.18, 10:51:
> On Fri, Jun 29, 2018 at 10:43 AM Michael Schmitz
wrote:
> > Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> > >>> Do we really need the warning?
> > >>> Once the parsing is fixed doing 64-bit math, it does not matter
> > >>> for
> > >>> Linux
Hi Michael.
Michael Schmitz - 29.06.18, 10:42:
> Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> >>> Do we really need the warning?
> >>> Once the parsing is fixed doing 64-bit math, it does not matter
> >>> for
> >>> Linux anymore.
> >>
> >> Well, irony of this is: In my case the RDB has
On Jun 29 2018, Michael Schmitz wrote:
> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
> to use it?
GPT has the concept of a protective MBR which should prevent such errors.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69
On 20180629 01:42, Michael Schmitz wrote:
Hi Geert,
Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
Do we really need the warning?
Once the parsing is fixed doing 64-bit math, it does not matter for
Linux anymore.
Well, irony of this is: In my case the RDB has been created on a machine
Hi Geert,
Am 29.06.18 um 21:12 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> On Fri, Jun 29, 2018 at 11:08 AM Michael Schmitz wrote:
>> Am 29.06.18 um 20:51 schrieb Geert Uytterhoeven:
Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
to use it?
>>> No idea...
>>>
Hi Geert,
Am 29.06.18 um 21:10 schrieb Geert Uytterhoeven:
>
>> The question is - can writes to the disk cause any damage to data on the
>> disk, as seen by old OS versions? If the answer is no, we won't need the
>> option after all.
> You mean someone relying on the parameters of his RDB to
Hi Michael,
On Fri, Jun 29, 2018 at 11:08 AM Michael Schmitz wrote:
> Am 29.06.18 um 20:51 schrieb Geert Uytterhoeven:
> >> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
> >> to use it?
> > No idea...
> >
> > Probably some old Windows or MacOS versions will just suggest
Hi Geert,
Am 28.06.18 um 01:30 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> Thanks for your patch!
>
> On Wed, Jun 27, 2018 at 4:47 AM wrote:
>> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
> ??
>
>> The Amiga RDB partition parser module uses int for partition sector
Hi Michael,
On Fri, Jun 29, 2018 at 10:58 AM Michael Schmitz wrote:
> Am 28.06.18 um 18:45 schrieb Geert Uytterhoeven:
> > On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
> > wrote:
> >> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > And as stated in my other reply to the patch:
>
Hi Geert,
Am 29.06.18 um 20:51 schrieb Geert Uytterhoeven:
> Hi Michael,
>
>> Would MSDOS recognize the GPT partition as 'probably FAT', and attempt
>> to use it?
> No idea...
>
> Probably some old Windows or MacOS versions will just suggest to
> format your "new" disk ;-)
Yep, that's what I'd
Hi Geert,
Am 28.06.18 um 18:45 schrieb Geert Uytterhoeven:
> Hi Michael,
>
> On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz wrote:
>> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> And as stated in my other reply to the patch:
> partition needs 64 bit disk device support in
Hi Michael,
On Fri, Jun 29, 2018 at 10:43 AM Michael Schmitz wrote:
> Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
> >>> Do we really need the warning?
> >>> Once the parsing is fixed doing 64-bit math, it does not matter for
> >>> Linux anymore.
> >> Well, irony of this is: In my case the
Hi Geert,
Am 28.06.18 um 21:25 schrieb Geert Uytterhoeven:
>
>>> Do we really need the warning?
>>> Once the parsing is fixed doing 64-bit math, it does not matter for
>>> Linux anymore.
>> Well, irony of this is: In my case the RDB has been created on a machine
>> with a native OS. So Linux
On 20180628 00:39, Geert Uytterhoeven wrote:
Hi Martin,
On Thu, Jun 28, 2018 at 9:29 AM Martin Steigerwald wrote:
Michael Schmitz - 28.06.18, 06:58:
[…]
In the interest of least surprises, we have to fix the 32 bit
overflow (so we can even detect that it would have happened), and
give the
Hi Joanne,
On Thu, Jun 28, 2018 at 11:20 AM jdow wrote:
> On 20180627 23:45, Geert Uytterhoeven wrote:
> > On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
> > wrote:
> >> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > And as stated in my other reply to the patch:
> > partition
Hi Martin,
On Thu, Jun 28, 2018 at 9:13 AM Martin Steigerwald wrote:
> Geert Uytterhoeven - 28.06.18, 08:45:
> > On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
> wrote:
> > > Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > > >>> And as stated in my other reply to the patch:
> > > >>>
On 20180627 23:45, Geert Uytterhoeven wrote:
Hi Michael,
On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz wrote:
Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
And as stated in my other reply to the patch:
partition needs 64 bit disk device support in AmigaOS or AmigaOS
like
operating
Hi Martin,
On Thu, Jun 28, 2018 at 9:29 AM Martin Steigerwald wrote:
> Michael Schmitz - 28.06.18, 06:58:
> […]
> > >> In the interest of least surprises, we have to fix the 32 bit
> > >> overflow (so we can even detect that it would have happened), and
> > >> give the user the chance to
Hi Michael.
Probably I was right with not submitting a patch myself. I´d likely
would have been overwhelmed by the discussion and feedback :)
Michael Schmitz - 28.06.18, 06:58:
[…]
> >> In the interest of least surprises, we have to fix the 32 bit
> >> overflow (so we can even detect that it
Hi Geert.
Geert Uytterhoeven - 28.06.18, 08:45:
> On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz
wrote:
> > Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> > >>> And as stated in my other reply to the patch:
> > >>> partition needs 64 bit disk device support in AmigaOS or AmigaOS
> > >>>
Hi Michael,
On Thu, Jun 28, 2018 at 6:59 AM Michael Schmitz wrote:
> Am 28.06.2018 um 09:20 schrieb Martin Steigerwald:
> >>> And as stated in my other reply to the patch:
> >>> partition needs 64 bit disk device support in AmigaOS or AmigaOS
> >>> like
> >>> operating systems (NSD64, TD64 or
Three issues exist here in two different places.
As far as a 32 TG disk is concerned RDBs can describe it and mount it safely -
sort of - modulo the following issues. They are not a problem, I believe, with
Amiga OSs new enough to understand RDBs. I cannot prove that. They are not
sufficient,
Error : Conventional RDBs cannot define more than 4,294,967,296 blocks.
or
Error : Conventional RDB block count overflow.
That is a HARD limit. The documentation for error should suggest larger
logical block (cluster, whatever) sizes as a way out. Of course, block size
"could" go
Warning: RDB partition 32-bit overflow
AmigaOS developers can do 64 bit math on a 32 bit operating system.
Just like Linux can.
Yes, I realize that. I hadn't gone back through all the mails on the
subject to find out what the exact requrements are on the AmigaOS
side.
Just trying to be as ter
Oops! It MUST be 64 bit or everything go boom.
{O.O}
On 20180627 06:30, Geert Uytterhoeven wrote:
Hi Michael,
Thanks for your patch!
On Wed, Jun 27, 2018 at 4:47 AM wrote:
From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
??
The Amiga RDB partition parser module
; >
> > Warning: RDB partition 32-bit overflow
> >
> > AmigaOS developers can do 64 bit math on a 32 bit operating system.
> > Just like Linux can.
>
> Yes, I realize that. I hadn't gone back through all the mails on the
> subject to find out what t
Hi Geert,
thanks for your feedback!
On Thu, Jun 28, 2018 at 1:30 AM, Geert Uytterhoeven
wrote:
> Hi Michael,
>
> Thanks for your patch!
>
> On Wed, Jun 27, 2018 at 4:47 AM wrote:
>> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
>
> ??
Comes from not using git
lopers can do 64 bit math on a 32 bit operating system. Just
> like Linux can.
Yes, I realize that. I hadn't gone back through all the mails on the
subject to find out what the exact requrements are on the AmigaOS
side.
Just trying to be as terse as possible to keep checkpatch happy :-(
Hi Michael,
Thanks for your patch!
On Wed, Jun 27, 2018 at 4:47 AM wrote:
> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
??
> The Amiga RDB partition parser module uses int for partition sector
> address and count, which will overflow for disks 2 TB and larger.
>
>
Thanks a lot again for your patch.
schmitz...@gmail.com - 27.06.18, 03:24:
> + if (start_sect > INT_MAX || nr_sects > INT_MAX
> + || (start_sect + nr_sects) > INT_MAX) {
> + pr_err("%s: Warning: RDB partition
> overflow!\n", +
schmitz...@gmail.com - 27.06.18, 03:24:
> From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
>
> The Amiga RDB partition parser module uses int for partition sector
> address and count, which will overflow for disks 2 TB and larger.
>
> Use sector_t as type for sector address
>From 5299e0e64dfb33ac3a1f3137b42178734ce20087 Mon Sep 17 00:00:00 2001
The Amiga RDB partition parser module uses int for partition sector
address and count, which will overflow for disks 2 TB and larger.
Use sector_t as type for sector address and size (as expected by
put_partition) to allow
Good Day,
I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing
Chong Hing Bank, Hong Kong, Chong Hing Bank Centre, 24 Des Voeux Road
Central, Hong Kong. I have a business proposal of $38,980,369.00.
All confirmable documents to back up the claims will be made available
to you
This patch enables scsi pm on systems where mq is explicitly disabled.
[PATCH v2 1/2] bcache: writeback rate shouldn't artifically clamp
[PATCH v2 2/2] bcache: rearrange writeback main thread ratelimit
This is a reroll of the previous "don't clamp" patch. It corrects
type issues where negative numbers were handled badly (mostly for
display in writeback_rate_debug).
subscribe linux-block
Subject: an iomap-based direct I/O implementation
Hi all,
this series adds a new direct I/O implementation based on the iomap
interface, and switches XFS to use it.
The first two patches are a resend of my earlier series to remove the
XFS iolock. They are needed for the lockdep assert
62 matches
Mail list logo
