Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

When Google releases their Chrome OS, my first prerequisite would be to work with my current files. What filesystems would it work with? (have read-write access). Would it support Windows partitions? (NTFS) and Unix partitions? (EXT/UFS). And lastly, which filesystem would it use natively and/or perform best with?

share|improve this question
maybe the title "What filesystems should Google Chrome OS work with?" would be better? –  Bruce McLeod Jul 17 '09 at 13:54

6 Answers 6

up vote 12 down vote accepted

As it's going to be based on the Linux kernel, I think you would be pretty safe in assuming it will support the usual ext3 filesystem.

It's impossible to guess what Google are going to do, but if they want to make any progress with their 'OS' they will need to ensure a maximum level of interoperability with existing systems to make the changeover as easy as possible for new users.

share|improve this answer
+1 for "It's impossible to guess what Google are going to do" –  innaM Jul 17 '09 at 9:54

My understanding is that Google OS will be built on top of Linux kernel, so file system support will be provided in the kernel layer. Expect anything typical for linux.

share|improve this answer

Depending on what exactly it is, it's possible that most of its storage will be "in the cloud".

That aside, as others have said, it's probably going to use the normal Linux-ey file systems. You'll likely be able to use FUSE to use other file systems with it.

share|improve this answer
Yeah, I'm pretty sure they'll publish some sort of GDrive service, but they'll definitely continue supporting all file systems common today. It wouldn't work otherwise. –  Blixt Jul 17 '09 at 8:06

It really depends on how easy Google wants to make for people to switch to their operating system.

If we look at when Microsoft introduced NT for the first time, it supported as much hardware and file systems as possible, and it continues to support both HFS, NTFS and FAT32 out of the box.

So if Google wants to build bridges to the ChromeOS, they should support HFS+, NTFS, FAT32 and ext3 that way it will ease transition and compatibility with other operating systems and maximise their chances of commercial success.

share|improve this answer
Wasn't it HPFS, not HFS, that Windows NT used? (HPFS isn't supported anymore though) –  grawity Jul 17 '09 at 8:42
I'm not sure about HPFS but HFS+ is the mac file system and windows server 2003 still supports it for its services for macintosh file sharing –  Bruce McLeod Jul 17 '09 at 13:53

Given that it is going to be targeted at Netbooks I don't think that native Windows FS support will be that high on the agenda. NTFS support is mainly useful if you are dual-booting and want to be able to access the other OS.

I would expect ext3 (possibly 4) for the native partition as well as CIFS for network shares, FAT(16/32) for mounting USB devices and possibly a FUSE based cloud storage (GDrive has been rumoured for a long time but I'm still not convinced it is coming).

Given that it is a Linux Kernel many other filesystems are potentially available but many will probably be dropped to minimise the install size and boot time.

share|improve this answer
I would argue that NTFS would be useful for attaching external harddrives and using those properly. –  kastermester Jul 17 '09 at 8:47
It would support NTFS, and the rest of the range that Linux works with, but there's no reason to use it internally. –  salmonmoose Aug 28 '09 at 22:25
NTFS runs nicely nowadays through ntfs-3g. Plus FAT and NTFS are useful for external HDDs. –  Ivan Vučica Oct 10 '09 at 15:14

On OS, distributed FS, cloud, caching, SVN, file Sharing... - my thoughts if it were I designing:

  • I would abstract the file system in to a generic service (more ...)
  • I would make your (netbook's, server's, phone's, ...) local storage available as part of "your-own" cloud (keywords: abstract, generic, composable, service). Think: composite, distributed, secured storage where your local files can be on your netbook whilst at the same time your OS' FS (server) is part of an abstract cloud - a grid-node, perhaps with automatic replication for most used files*, according to your cloud quota, and/or perhaps stored just accross you own computing devices (my 3 PCs at home, my Android device, ...); think Google FS (GFS) for me (or shareable).

This way, we could have the best of both worlds:

1) fast, local, access to your files (not just cached from remote cloud storage) without paying the penalty of disconnected/slow internet access

2) access all of your files from anywhere without being forced to send all your data to a 3rd party - love Google, but I must keep my data + 1TB isn't feasible in purist cloud; need a hybrid model - just leave your OS running (home server) if you want to keep your 1TB data always available.

Ex: this is something I do using with SVN, but this is not obviously not for everyone, and the ease of used and integration are not there. Some features which are part of SVN such as history, as well as optimizations such as keeping differences only and compression would be nice too. Well, and more, and more, and more... Microsoft has failed to innovate at all (no incentive of course) - lets hope Google does.


The above would be nice, but it only covers data storage. Another discussion would be regarding cloud computing and how apps could be designed to execute in parallel... Above: I might want my data local or remote... To-be-had: I want my processing units to be local or remote (composite processing). Other too: "local, remoted" add sharable to the equation so that we could share CPU and storage on the global distributed cloud, and get paid to do so???, or get some moster apps to run on a small embedded device (Android).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.