a6c31ca8b53a18d8
>
> Diff: https://git.reviewboard.kde.org/r/130090/diff/
>
>
> Testing
> ---
>
> I've written a little snippet to iterate through block devices, print their
> major/minor number, and their device properties. It was previously
> incorrectly labeling all my disks with major 0 and minor == device_number
> (since it was using the first 20 bits for the minor). It now correctly
> identifies their major/minor number.
>
>
> Thanks,
>
> KJ Tsanaktsidis
>
>
y
> realized it (which, in the area of disk i/o, never ceases to amaze) -
> https://lwn.net/Articles/682582/ (obvious followup question: what kernel do
> you use? this code seems to have landed in 4.10)
>
> KJ Tsanaktsidis wrote:
> I'm using kernel `Linux kj-hedt-arch 4.1
inor number, and their device properties. It was previously incorrectly
labeling all my disks with major 0 and minor == device_number (since it was
using the first 20 bits for the minor). It now correctly identifies their
major/minor number.
Thanks,
KJ Tsanaktsidis
> On April 28, 2017, 1:28 p.m., Lamarque Souza wrote:
> > Ship It!
>
> KJ Tsanaktsidis wrote:
> Great - thanks for your help and for bearing with my rusty C++! What
> happens now? I'm waiting on this patch to land for another patch I submi
130084/
- KJ
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103148
---
On April 23, 2017, 9:56 a.m., KJ Tsan
(). The part used to be required with cmake
> > 2.6.x, that is not true with cmake 3.x that we use nowadays.
>
> KJ Tsanaktsidis wrote:
> I'm not sure I understand here - elseif() needs to have the expression to
> match to enter the elseif() block? In any case I've
I worked out a cleaner way to do this using cmake generator expressions.
- KJ
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103087
---
incorrectly
labeling all my disks with major 0 and minor == device_number (since it was
using the first 20 bits for the minor). It now correctly identifies their
major/minor number.
Thanks,
KJ Tsanaktsidis
his is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103071
-------
On April 22, 2017, 12:38 a.m., KJ Tsanaktsidis wrote:
>
> ---
g the first 20 bits for the minor). It now correctly identifies their
major/minor number.
Thanks,
KJ Tsanaktsidis
reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103067
-------
On April 20, 2017, 8:49 a.m., KJ Tsanaktsidis wrote:
>
> ---
> This is an automatically generated e-m
vice_number (since it was
using the first 20 bits for the minor). It now correctly identifies their
major/minor number.
Thanks,
KJ Tsanaktsidis
ould also save some lines
> > in this patch.
> >
> > nitpik: add spaces around >>, like you did for & in the line below.
>
> KJ Tsanaktsidis wrote:
> Thanks for the review.
>
> * I would use upper case, but the macro is defined in `sys/s
20 bits for the minor). It now correctly identifies their
major/minor number.
Thanks,
KJ Tsanaktsidis
mber (since it was
using the first 20 bits for the minor). It now correctly identifies their
major/minor number.
Thanks,
KJ Tsanaktsidis
ed e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130090/#review103063
-------
On April 17, 2017, 8:42 a.m., KJ Tsanaktsidis wrote:
>
> ---
> This is an
with how often fsync should be called on my hardware, and I
found calling it every ~1M copied caused no decrease in copy performance whilst
still providing accurate progress info. That is the setting I've gone with in
this patch. I'm open to suggestions on how this could be tuned better though.
Thanks,
KJ Tsanaktsidis
y
> realized it (which, in the area of disk i/o, never ceases to amaze) -
> https://lwn.net/Articles/682582/ (obvious followup question: what kernel do
> you use? this code seems to have landed in 4.10)
>
> KJ Tsanaktsidis wrote:
> I'm using kernel `Linux kj-hedt-arch 4.1
he first 20 bits for the minor). It now correctly identifies their
major/minor number.
Thanks,
KJ Tsanaktsidis
- KJ
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/130084/#review103048
---
On April 15, 2017, 8:28 a.m., KJ Tsanakt
it every ~1M copied caused no decrease in copy performance whilst
still providing accurate progress info. That is the setting I've gone with in
this patch. I'm open to suggestions on how this could be tuned better though.
Thanks,
KJ Tsanaktsidis
tch. I'm open to suggestions on how this could be tuned better though.
Thanks,
KJ Tsanaktsidis
22 matches
Mail list logo
