Google Cloud Storage FUSE • Hacker News Board

Re: Google Cloud Storage FUSE

#21

Post by linsomniac » Tue, May 02, 2023, 1:13 PM UTC

MontyCarloHall wrote: post #7

I’ve experimented with using gcsfuse and its AWS equivalent, s3fs-fuse in production. At best, they are suited to niche applications; at worst, they are merely nice toys. The issue is that every file system operation is fundamentally an HTTP request, so the latency is several orders of magnitude higher than the equivalent disk operation. For certain applications that consistently read limited subsets of the filesyste…

>What I would really like to see is a two-tier cache system

Is there any sort of Linux HSM (Hieracrhical Storage Manager)? I haven't see any and have been a bit surprised nothing has really developed there. They can manage putting hot data in RAM, SSDs, colder or larger data on spinning rust, deep freezing onto a tape silo or a cloud storage...

Some of the NAS devices and RAID cards can support a two-tier caching or data migration using SSDs, where hot or highly-random data (usually identified by smaller write sizes) go to the SSDs, and then can migrate to the spinning discs.

I've done some "poor mans" version of this using LVM, where I can "pvmove" blocks of a logical volume between spinning discs and SSDs, which is pretty slick, but a very crude tool.

Re: Google Cloud Storage FUSE

#22

Post by [deleted] » Tue, May 02, 2023, 1:15 PM UTC

jefftk wrote: post #9

throwawaaarrgh wrote: post #6

Earlier quoted context omitted.

pretty standard limitation of object storage services iirc

Doesn't this mean that most programs you might want to use with the FUSE API won't actually work? They'll do fine for a while, until they try to seek, and then they'll get an error? Or is there a large group of programs that only ever write sequentially?

[deleted]

Re: Google Cloud Storage FUSE

#23

Post by ape4 » Tue, May 02, 2023, 1:17 PM UTC

MontyCarloHall wrote: post #7

I’ve experimented with using gcsfuse and its AWS equivalent, s3fs-fuse in production. At best, they are suited to niche applications; at worst, they are merely nice toys. The issue is that every file system operation is fundamentally an HTTP request, so the latency is several orders of magnitude higher than the equivalent disk operation. For certain applications that consistently read limited subsets of the filesyste…

That page shows a `mkdir` is 3 json commands. I wonder if its that many HTTP requests.

Re: Google Cloud Storage FUSE

#24

Post by 8organicbits » Tue, May 02, 2023, 1:19 PM UTC

MontyCarloHall wrote: post #7

I’ve experimented with using gcsfuse and its AWS equivalent, s3fs-fuse in production. At best, they are suited to niche applications; at worst, they are merely nice toys. The issue is that every file system operation is fundamentally an HTTP request, so the latency is several orders of magnitude higher than the equivalent disk operation. For certain applications that consistently read limited subsets of the filesyste…

Same experience. I remember opening a .docx in Word and watching it hang or studder at different operations. I think you'd need very reliable and low latency networking for this to be anything but a painful to use toy.

I'd be curious to see how it works running on EC2, especially with an S3 endpoint in the VPC. Although I still think you'd be better suited by using S3 as an object store, given the option to built it right.

Re: Google Cloud Storage FUSE

#25

Post by martius » Tue, May 02, 2023, 1:20 PM UTC

curt15 wrote: post #19

askvictor wrote: post #12

Now for official Google Drive support on Linux...

How do Googlers access Google Drive from their Linux workstations? Do they have an internal GDrive client?

Not that I know of, we have some virtual filesystems for specific things, but in general Drive is for shared docs, videos (recorded meetings/presentations) and things like this.

We don't use drive to store other files. Actually, we don't really "store files" since almost everything we need is remote.

See for instance this discussion: https://news.ycombinator.com/item?id=13561096

Re: Google Cloud Storage FUSE

#26

Post by hobo_mark » Tue, May 02, 2023, 1:21 PM UTC

ISL wrote: post #20

Can this be used to mount Drive under linux?

GCS is not Drive, it's Google's equivalent of S3.

Re: Google Cloud Storage FUSE

#27

Post by plaidfuji » Tue, May 02, 2023, 1:22 PM UTC

curt15 wrote: post #19

askvictor wrote: post #12

Now for official Google Drive support on Linux...

How do Googlers access Google Drive from their Linux workstations? Do they have an internal GDrive client?

I wonder the same, but I also wonder what the actual use case is for the Drive app on Linux. For me, Drive is mostly for syncing office docs (namely MS-office docs), PDFs and images among teams. That type of work doesn’t lend itself well to a Linux env anyway. And for programming-heavy sync tasks, a user will more likely use a remote Git repo for code and GCS for data. Does google even use MS office internally?

Re: Google Cloud Storage FUSE

#28

Post by jefftk » Tue, May 02, 2023, 1:24 PM UTC

hawski wrote: post #15

jefftk wrote: post #9

Earlier quoted context omitted.

Doesn't this mean that most programs you might want to use with the FUSE API won't actually work? They'll do fine for a while, until they try to seek, and then they'll get an error? Or is there a large group of programs that only ever write sequentially?

Most programs either write a full file every time and replace the old file by a single move or append to an old file. Writting in the middle could happen in a program writting to some kind of archive or disk image. There is probably a whole group of programs that do this I'm not familiar with, but I'm pretty sure of my first sentence.

I'm not completely confident (I tried looking in the source and it wasn't immediately obvious) but I think emacs does small in-place edits when you're working with very large files.

Re: Google Cloud Storage FUSE

#29

Post by ElectricalUnion » Tue, May 02, 2023, 1:27 PM UTC

rippercushions wrote: post #8

trollied wrote: post #3

Be aware that this is not free: "Cloud Storage FUSE is available free of charge, but the storage, metadata, and network I/O it generates to and from Cloud Storage are charged like any other Cloud Storage interface. In other words, all data transfer and operations performed by Cloud Storage FUSE map to Cloud Storage transfers and operations, and are charged accordingly."

Using FUSE doesn't cost you anything extra, but it doesn't make the underlying storage free.

You will be doing storage operations silently and in a unoptimized fashion, more so if the underlying FUSE filesystem is implemented in a naive fashion.

For example, Cloud Storage never moves or renames your objects; copying and deleting the original one instead. This can end up costing quite a lot if you're using data other that in "standard store" because of minimum storage duration.

Re: Google Cloud Storage FUSE

#30

Post by capableweb » Tue, May 02, 2023, 1:29 PM UTC

plaidfuji wrote: post #27

curt15 wrote: post #19

Earlier quoted context omitted.

How do Googlers access Google Drive from their Linux workstations? Do they have an internal GDrive client?

I wonder the same, but I also wonder what the actual use case is for the Drive app on Linux. For me, Drive is mostly for syncing office docs (namely MS-office docs), PDFs and images among teams. That type of work doesn’t lend itself well to a Linux env anyway. And for programming-heavy sync tasks, a user will more likely use a remote Git repo for code and GCS for data. Does google even use MS office internally?

> Does google even use MS office internally

That'd be weird, considering they have their own suite of office tools. Kind of like if Microsoft would be using Google Cloud rather than Azure internally.