5 ms·

I've come to the understanding that tape-drives are for people who need to "build a custom-sized storage solution", especially if you need capacity but not nece

I've come to the understanding that tape-drives are for people who need to "build a custom-sized storage solution", especially if you need capacity but not necessarily read/write speeds. A tape-drive is your read-heads. The tape is like a platter. The tape-library / jukebox is just a robotic mechanism for switching tapes into and/or out of the read-head. ---------- If you need a Petabyte of uncompressed storage, you can reach it with a tape-library consisting of 84 LTO8 tapes (12TB each). If read/write of 400MB/s is sufficient, one tape drive is sufficient. If you need faster access speeds, you buy a 2nd, 3rd, or 4th tape drive. So lets say you need 2GB/s read/write speed and a petabyte of storage. You simply get 4x LTO 8 drives, 84 LTO8 tapes, and stick them into a tape library of some kind. You then buy a certain amount of SSDs + HDDs sufficient for caching, so that you can read/write to this tape library at sufficient speeds (especially since it could be many minutes before a specific byte is accessed).

metadat 5y ago
What software is going to be gluing and integrating all these drives together into a usable interface? Does it already exist as open-source?
- dragontamer 5y ago
  LTFS (Linear Tape File System) shows each each "file" as often a pretty dumb "write-only" mechanism / append-only file system. That is: if a file A is modified, LTFS "represents" this by marking fileA as dead, then copying most of the contents of A to the end of the tape... with the few modifications in the correct location. Because tapes have so much capacity, this ends up working much better in practice than you'd expect. Especially if your backup-like software (or Apache-log files or whatever you're archiving) are largely append-only (ex: Wikipedia dumps or whatever huge data-storage requirements you're doing). ----------- Allegedly anyway, I don't really use tapes myself, but I amuse myself by looking at their specs / usability every now and then. It seems like the details of LTFS depend on each manufacturer's system, but it seems like LTFS itself is somewhat cross-compatible. Some LTFS-library docs suggest that different tapes are different folders. Others suggest that different tapes are mount/unmounted (which sends a sequence of commands to the little tape-robot to fetch the correct tape, which it does so by scanning barcodes or maybe going to correct slot) ----------- Tapes are meant to be used in a "jukebox-style" application IMO. If you need just one tape, you're doing it wrong. If you need 80-tapes, then doing it manually is obviously wrong, you should pay a bit extra for that "jukebox / tape-library" robot to fetch the right tapes automatically. > Does it already exist as open-source? Red Hat claims LTFS support. But I imagine this is only "disk-level LTFS", and not "library / robot LTFS".
  - metadat 5y ago
    Forgive my ignorance, does LTFS include the ability to use a pool of spinning rust or SSDs in front of it? That part sounded fancy and cool.
    - dragontamer 5y ago
      Oh, that sort of thing would be a tape-NAS sort of appliance and costs big $$$$. I know IBM talked about it before. I think here's their PDF of some university that did this: https://irp-cdn.multiscreensite.com/b076c94c/files/uploaded/FLAPE_IBM_EDGE_Presentation_FINAL.pdf https://irp-cdn.multiscreensite.com/b076c94c/files/uploaded/... --------------- The distributed data-thing is pretty common in the supercomputer world. I know that the nodes on the "Summit" supercomputer each have a local SSD for caching, and a centralized hard-drive array for longer-term storage. I'm pretty sure the software just manually copies the data around as necessary (that is: any software written for the supercomputer can copy data from the central storage into a local SSD). Supercomputers can have that kind of simplicity, because you buy 3000+ nodes with the same specs. So you know all nodes will have that 1.6TB SSD available. No matter which node your software ends up running on, the SSD location is set and obvious. It doesn't matter how the data is archived: you read it in and wait (it could be tape, hard drives, or any other mechanism)
bsdice 5y ago
Think about malware that encrypts everything on every HDD+SSD storage within reach in the company. Assume it somehow got all admin passwords. Doesn't even want money for the decryption key. What now? One method for business continuity would be LTO in a fire-proof safe to bootstrap the business back into life. Malware couldn't infect or encrypt the data on tape, because of the air gap and inherent "offline" nature.
- dragontamer 5y ago
  Except a backup NAS could accomplish the same thing. Or a backup to Backblaze / S3 storage or something. Lots of ways for the "all data was destroyed" situation to come out. Tapes are kinda-sorta useful for this situation because capacity is so so so cheap, you can keep full copies of the important data in your tape library pretty easily.
  - rodgerd 5y ago
    Malware authors are already adding hooks to delete data from Glacier, Netbackup, and other popular backup tools. If it's online, it's toast.
    - dragontamer 5y ago
      I guess for the truly paranoid, LTO / Tapes have that "Write-Once Read Many" feature if you really were worried about some virus overwriting your stuff.
      - rodgerd 5y ago
        Well, tapes have the ability to be easily removed, which is their killer feature vis-a-vis malware.

metadat 5y ago

What software is going to be gluing and integrating all these drives together into a usable interface? Does it already exist as open-source?

dragontamer 5y ago
LTFS (Linear Tape File System) shows each each "file" as often a pretty dumb "write-only" mechanism / append-only file system. That is: if a file A is modified, LTFS "represents" this by marking fileA as dead, then copying most of the contents of A to the end of the tape... with the few modifications in the correct location. Because tapes have so much capacity, this ends up working much better in practice than you'd expect. Especially if your backup-like software (or Apache-log files or whatever you're archiving) are largely append-only (ex: Wikipedia dumps or whatever huge data-storage requirements you're doing). ----------- Allegedly anyway, I don't really use tapes myself, but I amuse myself by looking at their specs / usability every now and then. It seems like the details of LTFS depend on each manufacturer's system, but it seems like LTFS itself is somewhat cross-compatible. Some LTFS-library docs suggest that different tapes are different folders. Others suggest that different tapes are mount/unmounted (which sends a sequence of commands to the little tape-robot to fetch the correct tape, which it does so by scanning barcodes or maybe going to correct slot) ----------- Tapes are meant to be used in a "jukebox-style" application IMO. If you need just one tape, you're doing it wrong. If you need 80-tapes, then doing it manually is obviously wrong, you should pay a bit extra for that "jukebox / tape-library" robot to fetch the right tapes automatically. > Does it already exist as open-source? Red Hat claims LTFS support. But I imagine this is only "disk-level LTFS", and not "library / robot LTFS".
- metadat 5y ago
  Forgive my ignorance, does LTFS include the ability to use a pool of spinning rust or SSDs in front of it? That part sounded fancy and cool.
  - dragontamer 5y ago
    Oh, that sort of thing would be a tape-NAS sort of appliance and costs big $$$$. I know IBM talked about it before. I think here's their PDF of some university that did this: https://irp-cdn.multiscreensite.com/b076c94c/files/uploaded/FLAPE_IBM_EDGE_Presentation_FINAL.pdf https://irp-cdn.multiscreensite.com/b076c94c/files/uploaded/... --------------- The distributed data-thing is pretty common in the supercomputer world. I know that the nodes on the "Summit" supercomputer each have a local SSD for caching, and a centralized hard-drive array for longer-term storage. I'm pretty sure the software just manually copies the data around as necessary (that is: any software written for the supercomputer can copy data from the central storage into a local SSD). Supercomputers can have that kind of simplicity, because you buy 3000+ nodes with the same specs. So you know all nodes will have that 1.6TB SSD available. No matter which node your software ends up running on, the SSD location is set and obvious. It doesn't matter how the data is archived: you read it in and wait (it could be tape, hard drives, or any other mechanism)

bsdice 5y ago

Think about malware that encrypts everything on every HDD+SSD storage within reach in the company. Assume it somehow got all admin passwords. Doesn't even want money for the decryption key. What now? One method for business continuity would be LTO in a fire-proof safe to bootstrap the business back into life. Malware couldn't infect or encrypt the data on tape, because of the air gap and inherent "offline" nature.

dragontamer 5y ago
Except a backup NAS could accomplish the same thing. Or a backup to Backblaze / S3 storage or something. Lots of ways for the "all data was destroyed" situation to come out. Tapes are kinda-sorta useful for this situation because capacity is so so so cheap, you can keep full copies of the important data in your tape library pretty easily.
- rodgerd 5y ago
  Malware authors are already adding hooks to delete data from Glacier, Netbackup, and other popular backup tools. If it's online, it's toast.
  - dragontamer 5y ago
    I guess for the truly paranoid, LTO / Tapes have that "Write-Once Read Many" feature if you really were worried about some virus overwriting your stuff.
    - rodgerd 5y ago
      Well, tapes have the ability to be easily removed, which is their killer feature vis-a-vis malware.