If HDDs weren't cheaper i would only use SSDs. and yes, the cheap
consumer stuff, like samsung 850 evo. Price is the only downside IMO.
often the usb3 hdd controllers are horrible, completely forgot about that :)
On Sun, 04 Feb 2018 11:02:57 +0100 hiro <23h...@gmail.com> wrote:
> For home use a ZFS intent log and caches on a good 2,5" SSD in a
> battery-backed thinkpad seems like an easy, silent, fast and stable
> (even against data loss from power outage) basis, even if you only
I am not familiar with the kirkwoods that you mentioned.
Just to be clear, the USB drive I was describing is rotating media in an
external enclosure, not a memory stick. Generally self powered, as powering
a portable hard drive from USB with a RPi is asking for trouble.
I have stopped buying
The problem is the index. It is heavily updated, and I had a Fossil
installation that ate my SSD in about 6 months. The log was OK, so I could
rebuild the index on another disk.
On Sat, Feb 3, 2018 at 10:39 AM, lchg wrote:
> As I know, fossil/venti file system is
Hey, thanks for explaining. this usage is surprisingly valid. I have
some much much older kirkwoods for the same scenario. The benefit is:
gigabit ethernet, higher stability, case included, power supply
included (and no power problems as on rpi), lower price.
I boot them all from USB HDDs, but I
static web pages, remote login (so that I can power/depower other hardware)
and file remote file distribution (via scp) mostly.
The main requirement is very low standby power consumption so that it can
survive on batteries which are recharged using solar panels.
Power consumption was the main
For home use a ZFS intent log and caches on a good 2,5" SSD in a
battery-backed thinkpad seems like an easy, silent, fast and stable
(even against data loss from power outage) basis, even if you only
connect shitty USB3 HDD drives externally for the pools. Your data
should be safe on the SSD as
> raspberry pi based servers
what are you serving?
> uSD in raspberry pi
there's the error
On Sat, 03 Feb 2018 21:46:42 + "Digby R.S. Tarvin"
Digby R.S. Tarvin writes:
> Thats why I described my use case - to make the MTBF figures meaningful. As
> I said, I have my system configured so that most heavy write accesses go to
> rotating media. I
Thats why I described my use case - to make the MTBF figures meaningful. As
I said, I have my system configured so that most heavy write accesses go to
rotating media. I typically try to have my system partitions mounted read
only, except var and tmp. I am currently using 32GB uSD devices for
On Sat, 03 Feb 2018 18:49:50 + "Digby R.S. Tarvin"
Digby R.S. Tarvin writes:
> My experience of running normal (read mostly) Linux filesystems on solid
> state media is that SSD is more robust but far less reliable than rotating
> MTBF for rotating
My experience of running normal (read mostly) Linux filesystems on solid
state media is that SSD is more robust but far less reliable than rotating
MTBF for rotating media for me has been around 10 years. MTBF for SSD has
been about 2. And the SSD always seems to fail catastrophically -
not so sure about mtbf. but it's too early to tell.
More the lidea of reading from the ssd first.
The way fs(4) driver works is you order your drives
with the first written at one end of the queue and first read at the other.
I assume the read rate and rotational latency of an ssd should
be better than hdd so I get the best performace.
what's the rationale behind writing to the hdd first?
i would say ssd is an excellent chiice for venti, the argument is less clear
for fossil which us much more like a traditional filesystem.
fossil and venti do not have the performance if a modern filesystem bur an ssd
can make them fast enough for most use (i dont stream movies from my plan9
On Sat, Feb 3, 2018, at 9:39 AM, lchg wrote:
> As I know, fossil/venti file system is log-structured, so it may be
> good for flash devices, especially in extending life of flash devices.
As far as I know the device itself will even the wear by remapping the
blocks it presents to the computer. I
Mail list logo