On Wed, Feb 11, 2009 at 10:33 AM, Steven Sim wrote:
> Tim;
>
> The proper procedure for ejecting a USB drive in Windows is to right click
> the device icon and eject the appropriate listed device.
>
I'm well aware of what the proper procedure is. My point is, I've done it
for years without for
(...)
Good. It looks like this thread can finally die. I received the
following in response to my message below:
(...)
I apologize that your eMail could not be delivered.
This is to either the mail server you use is considered as a machine from a
dynamic ip pool or your mail server is anywhere o
Tim;
The proper procedure for ejecting a USB drive in Windows is to right
click the device icon and eject the appropriate listed device.
I've done this before without ejecting and lost data before.
My personal experience with ZFS is that it is very reliable FS. I've
not lost data on it yet e
On Tue, Feb 10, 2009 at 11:44 PM, Fredrich Maney wrote:
>
> Ah... an illiterate AND idiotic bigot. Have you even read the manual
> or *ANY* of the replies to your posts? *YOU* caused the situation that
> resulted in your data being corrupted. Not Sun, not OpenSolaris, not
> ZFS and not anyone on t
On 11-Feb-09, at 10:08 AM, David Dyer-Bennet wrote:
On Tue, February 10, 2009 23:43, Uwe Dippel wrote:
1. Can the relevant people confirm that drives might turn dead when
leaving a pool at unfortunate moments? Despite of complete physical
integrity? [I'd really appreciate an answer here, bec
On Tue, February 10, 2009 23:43, Uwe Dippel wrote:
> 1. Can the relevant people confirm that drives might turn dead when
> leaving a pool at unfortunate moments? Despite of complete physical
> integrity? [I'd really appreciate an answer here, because this is what I
> am starting to implement here
On Tue, 10 Feb 2009 21:43:00 PST
Uwe Dippel wrote:
> Back to where I started from, with some questions:
> 1. Can the relevant people confirm that drives might turn dead when
> leaving a pool at unfortunate moments? Despite of complete physical
> integrity?
I have not experienced this. I -DID- ex
On 2/10/2009 4:48 PM, Roman V. Shaposhnik wrote:
On Wed, 2009-02-11 at 09:49 +1300, Ian Collins wrote:
These posts do sound like someone who is blaming their parents after
breaking a new toy before reading the instructions.
It looks like there's a serious denial of the fact that "bad
On 2/10/2009 3:37 PM, D. Eckert wrote:
(...)
Possibly so. But if you had that ufs/reiserfs on a LVM or on a RAID0
spanning removable drives, you probably wouldn't have been so lucky.
(...)
we are not talking about a RAID 5 array or an LVM. We are talking about a
single FS setup as a zpool over
> > > This is CR 6667683
> > >
> http://bugs.opensolaris.org/view_bug.do?bug_id=6667683
> >
> > I think that would solve 99% of ZFS corruption
> problems!
>
> Based on the reports I've seen to date, I think
> you're right.
>
> > Is there any EDT for this patch?
>
> Well, because of this thread,
[Still waiting for answers on my earlier questions]
So I take it that ZFS solves one problem perfectly well: Integrity of data
blocks. It uses CRC and atomic writes for this purpose, and as far as I could
follow this list, nobody has ever had any problems in this respect.
However, it also - at l
> > This is CR 6667683
> > http://bugs.opensolaris.org/view_bug.do?bug_id=6667683
>
> I think that would solve 99% of ZFS corruption problems!
Based on the reports I've seen to date, I think you're right.
> Is there any EDT for this patch?
Well, because of this thread, this has gone from "on my
> > "g" == Gino writes:
>
> g> we lost many zpools with multimillion$ EMC,
> Netapp and
> g> HDS arrays just simulating fc switches power
> fails.
> g> The problem is that ZFS can't properly
> recover itself.
> I don't like what you call ``the problem''---I think
> it assumes too
> much.
> Mario Goebbels wrote:
> >> The good news is that ZFS is getting popular
> enough on consumer-grade
> >> hardware. The bad news is that said hardware has
> a different set of
> >> failure modes, so it takes a bit of work to become
> resilient to them.
> >> This is pretty high on my short list.
>
> I'm rather tired of hearing this mantra.
> [...]
> Every file system needs a repair utility
Hey, wait a minute -- that's a mantra too!
I don't think there's actually any substantive disagreement here -- stating
that one doesn't need a separate program called /usr/sbin/fsck is not the
same as sa
Uwe Dippel wrote:
We have seen some unfortunate miscommunication here, and misinterpretation.
This extends into differences of culture. One of the vocal person in here is
surely not 'Anti-xyz'; rather I sense his intense desire to further the
progress by pointing his finger to some potential w
> Fsck can only repair known faults; known
> discrepancies in the meta data.
> Since ZFS doesn't have such known discrepancies,
> there's nothing to repair.
I'm rather tired of hearing this mantra.
If ZFS detects an error in part of its data structures, then there is clearly
something to repair.
In other words:
Dont feed the troll.
Greets
Jan Dreyer
zfs-discuss-boun...@opensolaris.org <> wrote :
> Good. It looks like this thread can finally die. I received the
> following in response to my message below:
>
>
>
>
> This is an automatically generated Delivery Status Notification
>
>
Good. It looks like this thread can finally die. I received the
following in response to my message below:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
cont...@desystems.cc
Technical details of permanent failure:
On Tue, Feb 10, 2009 at 4:14 PM, D. Eckert wrote:
> I think you are not reading carefully enough, and I
> can trace from your reply a typically American
> arrogant behavior.
>
> WE, THE PROUDEST AND infallibles on earth DID NEVER MAKE
> a mistake. It is just the stupid user who did not read the
>
We have seen some unfortunate miscommunication here, and misinterpretation.
This extends into differences of culture. One of the vocal person in here is
surely not 'Anti-xyz'; rather I sense his intense desire to further the
progress by pointing his finger to some potential wounds.
May I repeat
On February 10, 2009 1:14:57 PM -0800 "D. Eckert"
wrote:
I hope I've made myself very clear.
Very. Rarely has the adage "what one says reveals more about the
speaker than the subject" been more evident.
And as more postings we have to read in the sound of yours as more we are
thinking to
DE:
I think that a big part of the reason you're getting the responses you
do is not arrogance from Sun or us kool-aid drinkers, but your own tone
and attitude. You didn't ask for help in your initial message at all.
The entire post was a diatribe against Sun and ZFS which was based on
your exper
Roman V. Shaposhnik wrote:
On Wed, 2009-02-11 at 09:49 +1300, Ian Collins wrote:
These posts do sound like someone who is blaming their parents after
breaking a new toy before reading the instructions.
It looks like there's a serious denial of the fact that "bad things
do happen to eve
On Tue, 10 Feb 2009 13:14:57 PST
"D. Eckert" wrote:
> Hello? Did you already recognized the sound of the shot??
> I learned my lesson well, and in future this won't happen
> again, because we will no longer use zfs, but we have a legal
> interest, to get back our data we stored in trust on a non
Mario Goebbels wrote:
The good news is that ZFS is getting popular enough on consumer-grade
hardware. The bad news is that said hardware has a different set of
failure modes, so it takes a bit of work to become resilient to them.
This is pretty high on my short list.
One thing I'd like to
> "de" == D Eckert writes:
de> from your reply a typically American arrogant behavior.
de> WE, THE PROUDEST AND infallibles on earth DID NEVER MAKE a
de> mistake.
Maybe I should speak up since I defended you at the start. To my
view:
REASONABLE:
* expect that ZFS lose al
On Wed, 2009-02-11 at 09:49 +1300, Ian Collins wrote:
> These posts do sound like someone who is blaming their parents after
> breaking a new toy before reading the instructions.
It looks like there's a serious denial of the fact that "bad things
do happen to even the best of people" on this thre
if you are interested in my IP Address: no problem:
83.236.164.80
it just exactly approves my assumption, that's best and easier for someone - if
he's in the right position - to adhere a big pavement on someone's mouth to
avoid hearing a legal critique instead of discussing out the problem to f
I'll make a meta comment on the thread itself, not on the ZFS issue.
There is more bashing and broad accusations than it would normally happen on a
"professional usage" situation. Maybe a board admin can run a script on the ip
addresses logged and find a more subtle meaning... I don't know, I'm
> ps> This is a recommendation I would give even when you purchase
> ps> non-cheap battery backed hardware RAID controllers (I won't
> ps> mention any names or details to avoid bashing as I'm sure it's
> ps> not specific to the particular vendor I had problems with most
> ps> re
I think you are not reading carefully enough, and I
can trace from your reply a typically American
arrogant behavior.
WE, THE PROUDEST AND infallibles on earth DID NEVER MAKE
a mistake. It is just the stupid user who did not read the
fucking manual carefully enough.
Hello? Did you already
On Tue, Feb 10, 2009 at 12:31:05PM -0800, D. Eckert wrote:
> (...)
> You don't move a pool with 'zfs umount', that only unmounts a single zfs
> filesystem within a pool, but the pool is still active.. 'zpool export'
> releases the pool from the OS, then 'zpool import' on the other machine.
> (...)
DE - could you please post the output of your 'zpool umount usbhdd1'
command? I believe the output will prove useful to the point being
discussed below.
Charles
D. Eckert wrote:
> (...)
> You don't move a pool with 'zfs umount', that only unmounts a single zfs
> filesystem within a pool, but the
> The good news is that ZFS is getting popular enough on consumer-grade
> hardware. The bad news is that said hardware has a different set of
> failure modes, so it takes a bit of work to become resilient to them.
> This is pretty high on my short list.
One thing I'd like to see is an _easy_ opti
On 10-Feb-09, at 1:05 PM, Peter Schuller wrote:
YES! I recently discovered that VirtualBox apparently defaults to
ignoring flushes, which would, if true, introduce a failure mode
generally absent from real hardware (and eventually resulting in
consistency problems quite unexpected to the user w
D. Eckert wrote:
(...)
You don't move a pool with 'zfs umount', that only unmounts a single zfs
filesystem within a pool, but the pool is still active.. 'zpool export'
releases the pool from the OS, then 'zpool import' on the other machine.
(...)
with all respect: I never read such a non logic
D. Eckert wrote:
(...)
Possibly so. But if you had that ufs/reiserfs on a LVM or on a RAID0
spanning removable drives, you probably wouldn't have been so lucky.
(...)
we are not talking about a RAID 5 array or an LVM. We are talking about a
single FS setup as a zpool over the entire available d
(...)
Possibly so. But if you had that ufs/reiserfs on a LVM or on a RAID0
spanning removable drives, you probably wouldn't have been so lucky.
(...)
we are not talking about a RAID 5 array or an LVM. We are talking about a
single FS setup as a zpool over the entire available disk space on an ext
(...)
You don't move a pool with 'zfs umount', that only unmounts a single zfs
filesystem within a pool, but the pool is still active.. 'zpool export'
releases the pool from the OS, then 'zpool import' on the other machine.
(...)
with all respect: I never read such a non logic ridiculous .
I have
> "rs" == Roman Shaposhnik writes:
rs>1. as a forensics tool that would let you retrieve as much
rs> information as possible from a physically ill device
a nit, but I've never foudn fsck alone useful for this. Maybe for ``a
filesystem trashed by bad RAM/CPU/bugs'' it is usefu
On Tue, Feb 10, 2009 at 12:46 PM, Miles Nordin wrote:
>
> It's likely other filesystems are affected by ``the problem'' as I
> define it, just much less so. If that's the case, it'd be much better
> IMHO to fix the real problem once and for all, and find it so that it
> stays fixed, than to make
Hi,
i've followed this thread a bit and I think there are some correct
points on any side of the discussion, but here I see a misconception (at
least I think it is):
D. Eckert schrieb:
> (..)
> Dave made a mistake pulling out the drives with out exporting them first.
> For sure also UFS/XFS/EXT4/
On 2/10/2009 2:54 PM, D. Eckert wrote:
I disagree, see posting above.
ZFS just accepts it 2 or 3 times. after that, your data are passed away to
nirvana for no reason.
And it should be legal, to have an external USB drive with a ZFS. with all
respect, why should a user always care for redunda
On Feb 9, 2009, at 7:06 PM, Jeff Bonwick wrote:
>>There is no substitute for cord-yank tests - many and often. The
>>weird part is, the ZFS design team simulated millions of them.
>>So the full explanation remains to be uncovered?
>
>We simulated power failure; we did not simulate disks that simp
(...)
If anyone asks questions, they get no actual information, but a huge
amount of blame heaped on the sysadmin. Your post is a great example
of the typical way this problem is handled because it does both: deny
information and blame the sysadmin. Though I'm really picking on you
way too much her
On 2/10/2009 2:50 PM, D. Eckert wrote:
(..)
Dave made a mistake pulling out the drives with out exporting them first.
For sure also UFS/XFS/EXT4/.. doesn't like that kind of operations but only
with ZFS you risk to loose ALL your data.
that's the point!
(...)
I did that many times after perform
I disagree, see posting above.
ZFS just accepts it 2 or 3 times. after that, your data are passed away to
nirvana for no reason.
And it should be legal, to have an external USB drive with a ZFS. with all
respect, why should a user always care for redundancy, e. g. setup a mirror on
a single HD
(..)
Dave made a mistake pulling out the drives with out exporting them first.
For sure also UFS/XFS/EXT4/.. doesn't like that kind of operations but only
with ZFS you risk to loose ALL your data.
that's the point!
(...)
I did that many times after performing the umount cmd with ufs/reiserfs
fil
> "ps" == Peter Schuller writes:
ps> This is a recommendation I would give even when you purchase
ps> non-cheap battery backed hardware RAID controllers (I won't
ps> mention any names or details to avoid bashing as I'm sure it's
ps> not specific to the particular vendor I had
> "g" == Gino writes:
g> we lost many zpools with multimillion$ EMC, Netapp and
g> HDS arrays just simulating fc switches power fails.
g> The problem is that ZFS can't properly recover itself.
I don't like what you call ``the problem''---I think it assumes too
much. You m
> "jb" == Jeff Bonwick writes:
jb> We simulated power failure; we did not simulate disks that
jb> simply blow off write ordering. Any disk that you'd ever
jb> deploy in an enterprise or storage appliance context gets this
jb> right.
Did you simulate power failure of iSCSI/FC
On 10-Feb-09, at 1:03 PM, Charles Binford wrote:
Jeff, what do you mean by "disks that simply blow off write
ordering."?
My experience is that most enterprise disks are some flavor of
SCSI, and
host SCSI drivers almost ALWAYS use simple queue tags, implying the
target is free to re-order th
> on a UFS ore reiserfs such errors could be corrected.
In general, UFS has zero capability to actually fix real corruption in
any reliable way.
What you normally do with fsck is repairing *expected* inconsistencies
that the file system was *designed* to produce in the event of e.g. a
sudden rebo
> And again: Why should a 2 weeks old Seagate HDD suddenly be damaged, if there
> was no shock, hit or any other event like that?
I have no information about your particular situation, but you have to
remember the ZFS uncovers problems that otherwise go unnoticed. Just
personally on my private ha
> YES! I recently discovered that VirtualBox apparently defaults to
> ignoring flushes, which would, if true, introduce a failure mode
> generally absent from real hardware (and eventually resulting in
> consistency problems quite unexpected to the user who carefully
> configured her journa
Jeff, what do you mean by "disks that simply blow off write ordering."?
My experience is that most enterprise disks are some flavor of SCSI, and
host SCSI drivers almost ALWAYS use simple queue tags, implying the
target is free to re-order the commands for performance. Are talking
about something
> >However, I just want to state a warning, that ZFS is far from being that
> >what it
> >is promising, and so far from my sum of experience I can't recommend at all
> >to
> >use zfs on a professional system.
>
>
> Or, perhaps, you've given ZFS disks which are so broken that they are
> really
>
> The good news is that ZFS is getting popular enough on consumer-grade
> hardware. The bad news is that said hardware has a different set of
> failure modes, so it takes a bit of work to become resilient to them.
> This is pretty high on my short list.
So does this basically mean zfs rolls-ba
> What filesystem likes it when disks are pulled out from a LIVE
> filesystem? Try that on UFS and you're f** up too.
Pulling a disk from a live filesystem is the same as pulling the power
from the computer. All modern filesystems can handle that just fine.
UFS with logging on do not even need fsc
> On Mon, 09 Feb 2009 01:46:01 PST
> "D. Eckert" wrote:
>
> > after working for 1 month with ZFS on 2 external
> USB drives I have
> > experienced, that the all new zfs filesystem is the
> most unreliable
> > FS I have ever seen.
> >
> > Since working with the zfs, I have lost datas from:
> >
>
On Mon, 09 Feb 2009 01:46:01 PST
"D. Eckert" wrote:
> after working for 1 month with ZFS on 2 external USB drives I have
> experienced, that the all new zfs filesystem is the most unreliable
> FS I have ever seen.
>
> Since working with the zfs, I have lost datas from:
>
> 1 80 GB external Driv
> > There is no substitute for cord-yank tests - many
> and often. The
> > weird part is, the ZFS design team simulated
> millions of them.
> > So the full explanation remains to be uncovered?
>
> We simulated power failure; we did not simulate disks
> that simply
> blow off write ordering. Any
> There is no substitute for cord-yank tests - many and often. The
> weird part is, the ZFS design team simulated millions of them.
> So the full explanation remains to be uncovered?
We simulated power failure; we did not simulate disks that simply
blow off write ordering. Any disk that you'd e
On 9-Feb-09, at 6:17 PM, Miles Nordin wrote:
>> "ok" == Orvar Korvar writes:
>
> ok> You are not using ZFS correctly.
> ok> You have misunderstood how it is used. If you dont follow the
> ok> manual (which you havent) then any filesystem will cause
> ok> problems and corrupti
> "ok" == Orvar Korvar writes:
ok> You are not using ZFS correctly.
ok> You have misunderstood how it is used. If you dont follow the
ok> manual (which you havent) then any filesystem will cause
ok> problems and corruption, even ZFS or ntfs or FAT32, etc. You
ok> must use
* Orvar Korvar (knatte_fnatte_tja...@yahoo.com) wrote:
> Seagate7,
>
> You are not using ZFS correctly. You have misunderstood how it is
> used. If you dont follow the manual (which you havent) then any
> filesystem will cause problems and corruption, even ZFS or ntfs or
> FAT32, etc. You must use
Seagate7,
You are not using ZFS correctly. You have misunderstood how it is used. If you
dont follow the manual (which you havent) then any filesystem will cause
problems and corruption, even ZFS or ntfs or FAT32, etc. You must use ZFS
correctly. Start by reading the manual.
For ZFS to be able
On Mon, 9 Feb 2009, D. Eckert wrote:
>
> A good practice would be to care first for a proper documentation.
> There's nothing stated in the man pages, if USB zpools are used,
> that the zfs mount/unmount is NOT recommended and zpool export
> should be used instead.
I have been using USB mirrore
Kyle McDonald wrote:
> D. Eckert wrote:
>
>> too many words wasted, but not a single word, how to restore the data.
>>
>> I have read the man pages carefully. But again: there's nothing said, that
>> on USB drives zfs umount pool is not allowed.
>>
>>
> It is allowed. But it's not enoug
> too many words wasted, but not a single word, how to restore the data.
>
> I have read the man pages carefully. But again: there's nothing said,
> that on USB drives zfs umount pool is not allowed.
You misunderstand. This particular point has nothing to do with USB;
it's the same for any ZFS en
D. Eckert wrote:
> too many words wasted, but not a single word, how to restore the data.
>
> I have read the man pages carefully. But again: there's nothing said, that on
> USB drives zfs umount pool is not allowed.
>
It is allowed. But it's not enough. You need to read both the 'zpool '
and
Full of sympathy, I still feel you might as well relax a bit.
It is the XkbVariant that starts X without any chance to return.
But look at the many "boot stops after the third line", and from my side, the
not working network settings, even without nwam.
The worst part was a so-called engineer sta
>too many words wasted, but not a single word, how to restore the data.
>
>I have read the man pages carefully. But again: there's nothing said, that on
>USB drives zfs umount pool is not allowed.
You cannot unmount a pool.
You can only unmount a filesystem.
That the default name of the pool's
First: It sucks to loose data. That's very uncool...BUT
I don't know how ZFS should be able to recover data with no mirror to copy
from. If you have some kind of a RAID level you're easily able to recover your
data. I saw that several times. Without any problems and even with nearly no
performa
Hi Dave,
Having read through the whole thread, I think there are several things
that could all be adding to your problems.
At least some of which are not related to ZFS at all.
You mentioned the ZFS docs not warning you about this, and yet I know
the docs explictly tell you that:
1. While a ZF
too many words wasted, but not a single word, how to restore the data.
I have read the man pages carefully. But again: there's nothing said, that on
USB drives zfs umount pool is not allowed.
So how on earth should a simple user know that, if he knows that filesystems
properly unmounted using t
>James,
>
>on a UFS ore reiserfs such errors could be corrected.
That's not true. That depends on the nature of the error.
I've seen quite a few problems on UFS with corrupted file contents;
such filesystems always are "clean". Yet the filesystems are corrupted.
And no tool can fix those files
> bash-3.00# zfs mount usbhdd1
> cannot mount 'usbhdd1': E/A-Fehler
> bash-3.00#
Why is there an I/O error?
Is there any information logged to /var/adm/messages when this
I/O error is reported? E.g. timeout errors for the USB storage device?
--
This message posted from opensolaris.org
_
> on a UFS ore reiserfs such errors could be corrected.
I think some of these people are assuming your hard drive is broken. I'm not
sure what you're assuming, but if the hard drive is broken, I don't think ANY
file system can do anything about that.
At best, if the disk was in a RAID 5 array,
James,
on a UFS ore reiserfs such errors could be corrected.
It is grossly negligent to develop a file system without proper repairing tools.
More and more becomes clear, that it just was a marketing slogan by Sun to
state, that ZFS does not use any repairing tools due to healing itself.
In th
On Mon, 09 Feb 2009 03:10:21 -0800 (PST)
"D. Eckert" wrote:
> ok, so far so good.
>
> but how can I get my pool up and running
I can't help you with this bit
> bash-3.00# zpool status -xv usbhdd1
> Pool: usbhdd1
> Status: ONLINE
> Zustand: Auf mindestens einem Gerät ist ein Fehler
ok, so far so good.
but how can I get my pool up and running
Following output:
bash-3.00# zfs get all usbhdd1
NAME PROPERTY VALUE SOURCE
usbhdd1 type filesystem-
usbhdd1 creation Do Dez 25 23:36 2008 -
usbhdd1 used 3
>Well, umount is not the "right" way to do it, so he'd be simulating a
>power-loss/system-crash. That still doesn't explain why massive data loss
>would occur ? I would understand the last txg being lost, but 90% according
>to OP ?!
On USB or? I think he was trying to properly unmount the USB d
>
> "Unmount" is not sufficient.
>
Well, umount is not the "right" way to do it, so he'd be simulating a
power-loss/system-crash. That still doesn't explain why massive data loss
would occur ? I would understand the last txg being lost, but 90% according
to OP ?!
__
>However, the hardware used is:
>
>1 Sun Fire 280R Solaris 10 generic 10-08 latest updates
>1 Lenovo T61 Notebook running Solaris 10 genric 10-08 latest updates
>1 Sony VGN-NR38Z
>
>Harddrives in use: Trekstore 1 TB, Seagate momentus 7.200 rpm 2.5" 80 GB.
(Is that the Trekstore with 2x500GB)
>Th
D. Eckert wrote:
> Hi Caspar,
>
> thanks for you reply.
>
> I completely disagreed to your opinion, that is USB. And seems as well, that
> I am not the only one having this opinion regarding ZFS.
>
> However, the hardware used is:
>
> 1 Sun Fire 280R Solaris 10 generic 10-08 latest updates
> 1 Len
Hi Caspar,
thanks for you reply.
I completely disagreed to your opinion, that is USB. And seems as well, that I
am not the only one having this opinion regarding ZFS.
However, the hardware used is:
1 Sun Fire 280R Solaris 10 generic 10-08 latest updates
1 Lenovo T61 Notebook running Solaris 10
>However, I just want to state a warning, that ZFS is far from being that what
>it
>is promising, and so far from my sum of experience I can't recommend at all to
>use zfs on a professional system.
Or, perhaps, you've given ZFS disks which are so broken that they are
really unusable; it is US
On 09 February, 2009 - D. Eckert sent me these 1,5K bytes:
> Hi,
>
> after working for 1 month with ZFS on 2 external USB drives I have
> experienced, that the all new zfs filesystem is the most unreliable FS I have
> ever seen.
>
> Since working with the zfs, I have lost datas from:
>
> 1 80
Hi,
after working for 1 month with ZFS on 2 external USB drives I have experienced,
that the all new zfs filesystem is the most unreliable FS I have ever seen.
Since working with the zfs, I have lost datas from:
1 80 GB external Drive
1 1 Terrabyte external Drive
It is a shame, that zfs has no
101 - 191 of 191 matches
Mail list logo
