Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Testing two 18 TB white label SATA hard drives from datablocks.dev

ounapuu.ee

Post reply on HN
Print view View original

151–160 of 163 posts

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#151

Post by more_corn »

7bit wrote: post #126
userbinator wrote: post #91

Reading the part about using foam to make these drives quieter, and the link to the author's other article about putting drives on foam, makes me write this obligatory warning: hard drives do not like non-rigid mounting. Yes, the servo can usually still position the heads on the right track (since it's a servo), but power dissipation will be higher, performance will be lower, and you may get more errors with a non-ri…

I'm pretty sure whatever that community experienced is more anecdotal that statistically provable...

I’ve worked at a scale that is statistically relevant. Tens of thousands of drives under my control. I’ve seen a ton of different failure modes. Some of our anecdotes are actually useful. The problem with book and lab theory is that sometimes the theoretical problems don’t manifest (SSD wear out for example) and sometimes the minor seeming things turn out to matter a lot.

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#152

Post by tatersolid »

ghostly_s wrote: post #72
9dev wrote: post #53

Earlier quoted context omitted.

I don’t trust big channels especially , because I assume they have just sold themselves out to the biggest sponsor. Influencers only exist due to campaign deals, where companies try to sneak their ads into your mind by abusing your inclination to trust another human being. All of it is sickening. In comparison, I’d rather read a general review magazine with a long history. At least they don’t try to trick me into bel…

>I’d rather read a general review magazine with a long history. Do any of these still exist?

Consumer Reports

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#153

Post by hyperpl »

justsomehnguy wrote: post #146
CaptainOfCoit wrote: post #130

Earlier quoted context omitted.

How much would 18TB of SSDs cost compared to 18TB of HDDs? Probably a big reason why many go for HDDs still today.

SSDs are still roughly 3x per $/Tb. You can get a 8Tb QVO SATA drive for a like ~$300 so... ~$40/Tb

Where are you seeing 8TB (assuming you meant TB and Tb) for $300?

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#154

Post by hddherman »

justinclift wrote: post #123
hddherman wrote: post #17

Hello, author here! It's a nice surprise to notice my own post here, but the timing is unfortunate as I'm shuffling things around on my home server and will accidentally/intentionally take it offline for a bit. Here's a Wayback Machine copy of the page when that does happen: https://web.archive.org/web/20251006052340/https://ounapuu.e...

Have you considered 2nd hard enterprise SSDs? Sometimes larger sized models of those (15TB+) can be found with very good pricing. :)

I have considered going that route, but I'd have to switch to a platform that supports those formats and that will likely be too expensive for me as a hobbyist.

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#155

Post by lproven »

f_devd wrote: post #137
lproven wrote: post #117

Earlier quoted context omitted.

To be fair, your statement could be edited as follows to increase its accuracy: > btrfs is quite infamous for eating your data. This is the reason for the slogan on the bcachefs website: "The COW filesystem for Linux that won't eat your data". https://bcachefs.org/ After over a decade of in-kernel development, Btrfs still can't either give an accurate answer to `df -h`, or repair a damaged volume. Because it can't te…

> Btrfs still can't either give an accurate answer to `df -h`, or repair a damaged volume. > In my personal experience, writing to a full volume corrupts it irretrievably 100% of the time, and then it cannot be repaired. While I get the frustration, I think you could have probably resolved both of them by reading the manual. Btrfs separates metadata & regular data, meaning if you create a lot of small files your file…

Hi. My screen name is my real name, and my experience with Btrfs stems from the fact that I worked for SUSE for 4 years in the technical documentation department.

What that means is I wrote the manual.

Now, disclaimer, not that manual: I did not work on filesystems or Btrfs, not at all. (I worked on SUSE's now-axed-because-of-Rancher container distro CaaSP, and on SLE's support for persistent memory, and lots of other stuff that I've now forgotten because it was 4 whole years and it was very nearly 4 years ago.)

I am however one of the many people who have contributed to SUSE's excellent documentation, and while I didn't write the stuff about filesystems, it is an error to assume that I don't know anything about this. I really do. I had meetings with senior SUSE people where I attempted to discuss the critical weaknesses of Btrfs, and my points were pooh-poohed.

Some of them still stalk me on social media and regularly attack me, my skills, my knowledge, and my reputation. I block them where I can. Part of the price of being online and using one's real name. I get big famous people shouting that I am wrong sometimes. It happens. Rare indeed is the person who can refute me and falsify my claims. (Hell, rare enough is the person who knows the difference between "rebut" and "refute".)

So, no, while I accept that there may be workarounds that a smart human may be able to do, I strongly suspect that these things are accessible to software, to tools such as Zypper and Snapper.

In my repeated direct personal experience, using openSUSE Leap and openSUSE Tumbleweed, routine software upgrades can fill up the root filesystem. I presume this is because the packaging tools can't get accurate values for free space, probably because Btrfs can't accurately account for space used or about to be used by snapshots, and a corrupt Btrfs root filesystem can't be turned back into a valid consistent one using the automated tools provided.

Which is why both SUSE's and Btrfs's own docs say "do not use the repair tools unless you are instructed to by an expert."

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#156

Post by muro »

reliablereason wrote: post #121
leobg wrote: post #19

I was about to buy a NAS. I find the idea of using an old laptop instead interesting. Especially since it comes with UPS built in. The author is using a ThinkPad T430. Any experiences?

The laptop batteries tend to go bad(either just stop working or expand and become a major fire hazard) after a year or two as they are not built to be fully charged for years on end. I tried doing it twice and that is what happened both times. Would not recommend; if you want a UPS just buy one, the small ones are not that expensive, like 70 USD.

After a year or two is exaggerating - it's rare to see issues within 5 years.

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#157

Post by scottlamb »

master_crab wrote: post #138
scottlamb wrote: post #136

Earlier quoted context omitted.

> And if you need a good fan that’s quiet enough for the CPU, you’re looking at 4U. Depends on the CPU, I imagine. I'm using one with a 65W TDP. I'm hopeful that I can cool that quietly with air in 2U, without having to nerf it with lower BIOS settings. Many NASs have even lower power CPUs like the Intel N97 and friends.

Oh yes, you can definitely get away with much less for something like that or an ARM, Ryzen embedded chips, etc. The 4U is more for full scale desktop CPUs like the i9-12900k I am running (like an NH-D15 sink/fan). You may even be able to get away with passive cooling at the 65W range.

> You may even be able to get away with passive cooling at the 65W range.

I saw there's a "passive" Dynatron A43, which even claims to handle up to 155W. My understanding is that most/all server motherboards will have the socket oriented so the fins are front-to-back and the RAM is off to the side. And then you have chassis fans blowing air front-to-back, so I think they basically double as the CPU fan. (Which is also what the older motherboard that came in my CSE-813M did.) I air-quoted passive because I think it needs those chassis fans, but there's not one on the CPU anyway. And I'm not sure I completely trust the A43's rating, but with this setup I think it'd be fine for my 65 W TDP CPU at least.

On the other hand, I'm using a cheap gaming motherboard with fins sideways, RAM blocking the front-to-back airflow. My gut says that Dynatron A43 wouldn't do well. I don't understand why this orientation is desirable for desktops; my conspiracy theorist side says they make the consumers ones this way so they won't eat into the rack-mounted server market share. I am kinda tempted to get a server motherboard for this and IPMI (and/or at least serial port-accessible BIOS), but I started by looking at budget NASes and things have already spiraled a bit from there.

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#158

Post by justsomehnguy »

hyperpl wrote: post #153
justsomehnguy wrote: post #146

Earlier quoted context omitted.

SSDs are still roughly 3x per $/Tb. You can get a 8Tb QVO SATA drive for a like ~$300 so... ~$40/Tb

Where are you seeing 8TB (assuming you meant TB and Tb) for $300?

At Amazon. Guess I needed to check it better. Also I shouldn't did it in a bar. sigh

Anyway, I have a spreadsheet with both the prices and $/Gb/Tb so I just copy the relevant part here and hope formatting would persist:

    $/Tb Item Interface Capacity Price, $
     $90 SSD 4Tb Samsung 870 QVO (MZ-77Q4T0BW) SATA3 4000 $359
     $96 SSD 2Tb Samsung 870 QVO (MZ-77Q2T0BW) SATA3 2000 $192
    $102 USB 1Tb SanDisk Ultra Dual Drive Go (SDDDC3-1T00-G46) USB 1000 $102
    $103 SSD Samsung PM1643a MZILT3T8HBLS-00007 3.84T (root) SAS 3840 $394
    $104 SSD 4Tb Samsung 870 EVO (MZ-77E4T0BW) SATA3 4000 $417
    $105 SSD 2Tb Transcend 225S (TS2TSSD225S) SATA3 2000 $210
    $106 SSD 4Tb Transcend 230S (TS4TSSD230S) SATA3 4000 $425
    $107 SDXC 2Tb MicroSD SanDisk Extreme (SDSQXAV-2T00-GN6MN) SDXC 2000 $215
    $109 SSD 2Tb Samsung 870 EVO (MZ-77E2T0BW) SATA3 2000 $217
    $111 SSD 2Tb Kingston KC600 Series (SKC600/2048G) SATA3 2000 $223
    $115 SSD 8Tb Samsung 870 QVO (MZ-77Q8T0BW) SATA3 8000 $923
    $128 SSD 7.68Tb Samsung PM9A3 (MZQL27T6HBLA-00A07) OEM U.2 7680 $985
    $129 SSD 1Tb Samsung 870 EVO (MZ-77E1T0BW) SATA3 1000 $129
    $134 SSD 3.2Tb Intel P4610 Series (SSDPE2KE032T801) U.2 3200 $430
    $140 SSD 1.6Tb Intel P4610 Series (SSDPE2KE016T801) U.2 1600 $224
So 8Tb QVO are $115/TB.

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#159

Post by f_devd »

lproven wrote: post #155
f_devd wrote: post #137

Earlier quoted context omitted.

> Btrfs still can't either give an accurate answer to `df -h`, or repair a damaged volume. > In my personal experience, writing to a full volume corrupts it irretrievably 100% of the time, and then it cannot be repaired. While I get the frustration, I think you could have probably resolved both of them by reading the manual. Btrfs separates metadata & regular data, meaning if you create a lot of small files your file…

Hi. My screen name is my real name, and my experience with Btrfs stems from the fact that I worked for SUSE for 4 years in the technical documentation department. What that means is I wrote the manual . Now, disclaimer, not that manual: I did not work on filesystems or Btrfs, not at all. (I worked on SUSE's now-axed-because-of-Rancher container distro CaaSP, and on SLE's support for persistent memory, and lots of oth…

Hey. That's sounds like an awful experience. Btrfs has some rough edges especially since a lot of maintenance tasks are "manual", and you are right to try and address it. And it's annoying that becomes personal for some people with too much time.

For my perspective, my experience with btrfs has been flawless through 11 machines and at least 3 major releases on each without any maintenance but it could just be I'm not hitting the worst case (only use snapshots on 2 machines, raid on 3). And I've only used btrfs since fairly recently (~4 years now). I've had to recover one drive of a friend using the method I outlined before as he filled the entire drive with media. For me the trade-off of a few rough edges but more functionality & flexibility than other filesystems is worth it.

For your update issue, I think you're mostly correct; the package manager likely assumes the filesystem is not snapshotted (i.e. it will reclaim disk space), while btrfs with snapshots/CoW will use the entire size of written files unless it's in the same snapshot.

Re: Testing two 18 TB white label SATA hard drives from datablocks.dev

#160

Post by lproven »

f_devd wrote: post #159
lproven wrote: post #155

Earlier quoted context omitted.

Hi. My screen name is my real name, and my experience with Btrfs stems from the fact that I worked for SUSE for 4 years in the technical documentation department. What that means is I wrote the manual . Now, disclaimer, not that manual: I did not work on filesystems or Btrfs, not at all. (I worked on SUSE's now-axed-because-of-Rancher container distro CaaSP, and on SLE's support for persistent memory, and lots of oth…

Hey. That's sounds like an awful experience. Btrfs has some rough edges especially since a lot of maintenance tasks are "manual", and you are right to try and address it. And it's annoying that becomes personal for some people with too much time. For my perspective, my experience with btrfs has been flawless through 11 machines and at least 3 major releases on each without any maintenance but it could just be I'm not…

Thanks for that response.

It's a balance. All of life is a balance.

I worked at Red Hat very briefly, and for SUSE for longer than ever before. Both were good workplaces with a good atmosphere: RH is one of the friendliest places ever, and I'm still friends with former colleagues from over a decade ago.

OTOH, installing Fedora 14 was like having a bucket of cold water to the face. I used and reviewed Red Hat Linux in the 1990s and it was a massive PITA. It had no automatic dependency resolution, so complex software installation (e.g. going from KDE 1.x to KDE 2.x) was a huge task involving manually installing hundreds of dependencies.

RH would not bundle KDE (because Qt was not 100% FOSS) -- which is also why Mandrake was founded -- and so the GUIs on RHL were poor.

I switched to SUSE. Good package management, good GUIs, good system-management tools. (YaST was way better than RH's inadequate `linuxconf`.)

RH "fixed" this by... removing Linuxconf.

Trying Fedora a decade later and it was just as bad. All the external bits improved because upstream improved. GNOME was still a mess. KDE had got much more bloated. Xfce was better than ever.

But the RH in-house bits, while having nice visual design, were functionally terrible. The installer was an embarassment.

Over a decade of work since I reviewed RHL 9 and it was worse than ever.

A few years later, go to work at SUSE, and hey, openSUSE was lovely. All the good bits still there and improved. Yeah, a bit bigger and slower and clunkier than Ubuntu.

But there's always a downside.

An older team so less party atmosphere. Fewer "team building" sessions in the pub.

And while I was away, SUSE switched from ReiserFS to Btrfs, and as usual, SUSE of old being fond of experimental bleeding-edge filesystems, it's half-implemented and doesn't work right.

Snapper doesn't prune snapshots thoroughly enough. It fills your disk and because of unimplemented or non-working features it can't tell when this will happen.

Official SUSE answer: give it lots of space. Here, our FS falls over unrepairably when full, so give it all your space so it won't fill up! And you can't repair it so take lots of backups!

Every distro has downsides. Every filesystem has downsides but they are much less obvious.

Btrfs made my openSUSE boxes collapse and crash 2-3 times a year for 4 years. That is intolerable. I put up with that kind of crashy junk in 1997 or so but not 20 years later.

Post reply on HN