Am 06.01.2014 17:31, schrieb Stefan G. Weichinger:
> The Vertex3 seems to be way faster.
the vertex3 is 60GB while the older Intel is 80GB ... not so good ...
But I made some small progress in booting the thinkpad with BFQ-enabled
kernel. Somehow the encrypted swap seems to have stopped things.
Am 06.01.2014 17:16, schrieb Stefan G. Weichinger:
> Am 06.01.2014 16:40, schrieb Neil Bothwick:
>> On Mon, 06 Jan 2014 16:31:55 +0100, Stefan G. Weichinger wrote:
>>
>>> How to migrate? dd isn't recommended, right?
>>>
>>> rsync the partitions one by one? But one of them is encrypted
>>> ...
>>
>>
Am 06.01.2014 16:40, schrieb Neil Bothwick:
> On Mon, 06 Jan 2014 16:31:55 +0100, Stefan G. Weichinger wrote:
>
>> How to migrate? dd isn't recommended, right?
>>
>> rsync the partitions one by one? But one of them is encrypted
>> ...
>
> Set up a new encrypted partition and rsync the contents.
On Mon, 06 Jan 2014 16:31:55 +0100, Stefan G. Weichinger wrote:
> How to migrate? dd isn't recommended, right?
>
> rsync the partitions one by one? But one of them is encrypted ...
Set up a new encrypted partition and rsync the contents.
--
Neil Bothwick
Bagpipe for free: Stuff cat under arm
I consider swapping SSDs ... the Vertex3 from my desktop (replaced by
the new Samsung 840 EVO) could replace the even older Intel SSD.
I assume that the Vertex3 would be faster than the Intel ... (at least
one generation younger).
How to migrate? dd isn't recommended, right?
rsync the partition
Am 03.01.2014 23:14, schrieb Stefan G. Weichinger:
> currently fiddling with my thinkpad hanging at boot ... so still no BFQ
> for that laptop ... :-(
I don't get it. My thinkpad hangs repeatedly a booting and I don't
really know how to spot the reason.
As you may remember I run systemd as init-
Alan McKinnon writes:
> that's expected, BFQ isn't in mainline
Nor is it in Gentoo hardened-sources.
Am 03.01.2014 15:07, schrieb Alan McKinnon:
> On 03/01/2014 15:13, William Kenworthy wrote:
>> On 03/01/14 15:34, Alan McKinnon wrote:
>>> On 03/01/2014 09:25, Stefan G. Weichinger wrote:
Am 03.01.2014 07:52, schrieb Alan McKinnon:
> On 03/01/2014 00:46, Stefan G. Weichinger wrote:
>>
Am 03.01.2014 23:12, schrieb Alan McKinnon:
> On 04/01/2014 00:01, Stefan G. Weichinger wrote:
>> Am 03.01.2014 22:59, schrieb Alan McKinnon:
>>
>>> that's expected, BFQ isn't in mainline
>>
>> (being lazy): why, btw ?
>>
>>
>>
>>
>
>
> dunno really, it's just not there yet.
;-)
currently fiddl
On 04/01/2014 00:01, Stefan G. Weichinger wrote:
> Am 03.01.2014 22:59, schrieb Alan McKinnon:
>
>> that's expected, BFQ isn't in mainline
>
> (being lazy): why, btw ?
>
>
>
>
dunno really, it's just not there yet.
--
Alan McKinnon
alan.mckin...@gmail.com
Am 03.01.2014 22:59, schrieb Alan McKinnon:
> that's expected, BFQ isn't in mainline
(being lazy): why, btw ?
On 03/01/2014 23:52, Stefan G. Weichinger wrote:
> Am 03.01.2014 15:07, schrieb Alan McKinnon:
>
>> I'd like to see the results of any benchmarks you do with BFQ on VMs
>
> If we run BFQ on the host (as it runs SSDs and HDDs and we want it to be
> snappy) this would maybe mean that in the VMs we
Am 03.01.2014 15:07, schrieb Alan McKinnon:
> I'd like to see the results of any benchmarks you do with BFQ on VMs
If we run BFQ on the host (as it runs SSDs and HDDs and we want it to be
snappy) this would maybe mean that in the VMs we need Noop ?
In the IBM-pdf "Best practices for KVM" they te
Am 03.01.2014 15:07, schrieb Alan McKinnon:
>> hmm, is BFQ good for VM's too? I am currently using noops (storage is
>> ceph) and was going to experiment but have not had the time yet.
>
>
> I have no idea, but I'd like to find out.
>
> Instinct tells me one of the host or guest should be NOOP
On 03/01/2014 15:13, William Kenworthy wrote:
> On 03/01/14 15:34, Alan McKinnon wrote:
>> On 03/01/2014 09:25, Stefan G. Weichinger wrote:
>>> Am 03.01.2014 07:52, schrieb Alan McKinnon:
On 03/01/2014 00:46, Stefan G. Weichinger wrote:
> BFQ only for the SSDs ?
Yes. The schedule
On 03/01/14 15:34, Alan McKinnon wrote:
> On 03/01/2014 09:25, Stefan G. Weichinger wrote:
>> Am 03.01.2014 07:52, schrieb Alan McKinnon:
>>> On 03/01/2014 00:46, Stefan G. Weichinger wrote:
BFQ only for the SSDs ?
>>>
>>> Yes. The scheduler knows how to deal with SSDs while keeping everything
Am 03.01.2014 08:34, schrieb Alan McKinnon:
> BFQ for both is the recommendation.
>
> But do try it both ways to see how it performs and compare.
sure, thanks.
So I edit my udev-rules (and could leave them away and simply compile
bfq in as default if needed).
On 03/01/2014 09:25, Stefan G. Weichinger wrote:
> Am 03.01.2014 07:52, schrieb Alan McKinnon:
>> On 03/01/2014 00:46, Stefan G. Weichinger wrote:
>>> BFQ only for the SSDs ?
>>
>> Yes. The scheduler knows how to deal with SSDs while keeping everything
>> responsive even under load.
>>
>> BFQ seems
Am 03.01.2014 07:52, schrieb Alan McKinnon:
> On 03/01/2014 00:46, Stefan G. Weichinger wrote:
>> BFQ only for the SSDs ?
>
> Yes. The scheduler knows how to deal with SSDs while keeping everything
> responsive even under load.
>
> BFQ seems a good fit for your workcase - desktop/laptop. For thos
On 03/01/2014 00:46, Stefan G. Weichinger wrote:
> Am 02.01.2014 23:39, schrieb Alan McKinnon:
>
>> Give BFQ a try, set USE=experimental in *-sources to patch the source
>>
>> euses -sf experimental giove further info and links
>
> thanks for the hint ...
>
> edited USE-flags and re-emerging sou
Am 02.01.2014 23:59, schrieb Anton Shumskyi:
> And the best guide is at Arch wiki=) As always=)
> https://wiki.archlinux.org/index.php/Solid_State_Drives
been there before ;-)
Hi, there is a native queuing at my INTEL SSD 64GB, so i'v set "noop"
scheduler via udev rules. And it's kind a luggish when deleting a lot files
like kernel sources (at ext4,xfs,btrfs, FS makes no difference, some cheap
hardware stuff). Will test some day another scheduler like "deadline" on
top
Am 02.01.2014 23:39, schrieb Alan McKinnon:
> Give BFQ a try, set USE=experimental in *-sources to patch the source
>
> euses -sf experimental giove further info and links
thanks for the hint ...
edited USE-flags and re-emerging sources ...
BFQ only for the SSDs ?
On 03/01/2014 00:23, Stefan G. Weichinger wrote:
> Am 02.01.2014 23:17, schrieb Alan McKinnon:
>
>> Before you test other fs's, do you use BFQ? What IO scheduler do you use?
>
> for SSD(s): noop
> for HDD(s): cfq
>
> both triggered/set via udev-rules
>
>
>
>
>
Give BFQ a try, set USE=expe
Am 02.01.2014 23:17, schrieb Alan McKinnon:
> Before you test other fs's, do you use BFQ? What IO scheduler do you use?
for SSD(s): noop
for HDD(s): cfq
both triggered/set via udev-rules
On 03/01/2014 00:14, Stefan G. Weichinger wrote:
>
> I am running both my desktop and laptop on SSDs for years now.
>
> I think I got the basic things right:
>
> proper alignment of partitions, scheduler, TRIM (fstrim) ... you know.
>
> Today I received my new and shiny Samsung 840 EVO and migr
26 matches
Mail list logo
