Slashdot Mirror
Windows Alternatives to NTFS?
Maidjeurtam asks: "I'm a multi-OS user. Although Linux is what I use the most these days (I run it on my primary P4 box and on my iBook), I also run Mac OS X and a Windows XP on other machines. Of course, those boxes are networked, but sometimes, I just prefer to plug one machine's hard disk into another. I often work with big DV files (> 4GiB) and it looks like I have no other choice than having a different filesystem on each of my boxes. Granted, Linux can read NTFS (Macs can too) and even write to NTFS partitions thanks to tools like Captive, but I don't like the idea of running Windows code on my Linux box. In fact, I don't want my data stored on a proprietary, closed filesystem. I've googled a bit and it seems there's no modern (free-as-in-speech) filesystem I can install on Windows. I'd love to have ReiserFS running on my XP box, for example. Am I condemned to stay with NTFS, or do you guys know of a Windows-compatible, open filesystem that I can use?"
Last I checked, you couldn't have files over 4 gb in size on a FAT partition.
What we did for file systems was standardize on ISO9660 throughout, though we are considering a move to UFS so we have support for larger files. Windows supports it, though you have to hack the registry to get write access enabled, and we ended up writing a custom "disk format" tool to actually get disks initialised because, needless to say, W2K doesn't actually allow you to format disks as ISO9660 by default.
Well recommended. There are some neat features of ISO9660, like the VAX/VMS style "versions" for instance. Unfortunately, bog standard ISO9660 has crappy 32.3 style filenames (and for maximum compatability we're encouraged to just do 8.3), so it's not a perfect solution (another reason we want to switch to UFS.)
Definitely recommended though. It's a little slow, but everything will read it.
http://www.daniweb.com/techtalkforums/showthread.p hp?t=693
/* oops I accidentally made a comment, sorry */
looks like it may be alittle old, but it may work
Reiserfs under windows
I was actually thinking about this a few days ago. There's lots of work out there getting linux to run windows drivers, but I haven't seen much work on writing windows drivers for posix (*nix, whatever) stuff.
A while ago I downloaded the Windows DDK from Microsoft for something, but I didn't end up using it, uninstalled it and now I can't find the download. Unfortunately, it doesn't seem avail. for free from Microsoft's site anymore either (Microsoft WHDC DDK page). I have work to do, but this page seems like it might be of some help: OSROnline.com... maybe.
Anyways, the idea still stands, why aren't there win32 branches of open source file system drivers? Of course, I know squat about writing drivers, especially filesystem drivers, so there may be a damn good reason why not. But figured I'd throw it out anywho.
DONT PANIC
In fact, I don't want my data stored on a proprietary, closed filesystem.
Hmm, then maybe don't use Windows?! Seriously, why complain about the file system in particular when the entire OS is closed source. It's one thing to say "I only use OSS," but it's another to say "I don't mind closed source software, except for on this one part - there it's bad."
Windows is optimized for NTFS now, and NTFS is good. If you don't want propritary stuff, don't use Windows, period.
Explore ex2fs
I'd love to have ReiserFS running on my XP box, for example.
Reiser is not really appropriate here, because you want a filesystem for "large" files. Reiser's strength and efficiency is in large numbers of small files.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
1) You don't know that he doesn't work for pixar, or that his work is not of value. Insulting his needs is not an answer to the question, it's the bitter bitching of a troll.
2) The poster, as you so unusefully point out, is aware of read access under Mac OS X and Linux, and is perfectly aware that he doesn't have an _access_ problem per se. He does, however, have an _access_ problem in that he can only write from one side. If he needs to write from the other he needs to move the files off box.
3) Apparently you're reading things the rest of us aren't. The poster is not complaining about things just because they're proprietary. What he is asking is if there is a way to do what he wants to do. You fail miserably to even address his issue in your brief rant.
To the moderator or called you 'insightful'. Stop smoking crack, it makes you feed the trolls.
-T
Suck my Karma Bonus.
Old truckers never die, they just get a new peterbilt
- Am I condemned to stay with NTFS?
Yes, as long as you want stability and consistenty (as in error recovery, such as provided by metadata journaling), you are.Windows supports FAT32 and ISO9660 out of the box. FAT32 does not provide enough error recovery to be recommendable. People using ISO9660 as a hard-drive file system are crazy masochists -- enough said. There are seemingly abandoned ports of Ext2 and ReiserFS out there. None of them are in any sense stable for production use.
Why aren't there more file systems available on Windows? The first clue is that Windows is not an open-source platform; open-source hackers tend to live on open-source platforms. The people who work on kernel-level development under Windows are likely to be pursuing commercial software from the outset.
Furthermore, Windows kernel development is something of a black art; it is hard enough that you need to have some vested interest in the platform in order to stay; you would want to live and breathe Windows kernel APIs. (APIs, incidentally, that don't seem constructed for use by humans; for example, due to the limited size of the kernel addressing space, there are several different "kinds" of memory you must carefully allocate and manage yourself. Add to this the awkwardness involved in debugging this stuff, the poor kernel-level development tools offered by Microsoft, the limited documentation, the fact that much third-party information is non-gratis, and of course that the kernel sources themselves are closed, and you have one painful hobby.) In short, you would want to become a kernel specialist.
These painfully-accrued skills are worth their weight in gold, and used to leverage careers as highly-paid consultants or highly-paid trainers, or both. And some, of course, are driver writers for hardware companies.
There's a further reason: Linux file system drivers, in my experience, are designed to be, well, Linux file system drivers. Witness the amount of effort taken by IBM and SGI to port their proprietary journaling file systems to Linux -- and this was from one Unix-like kernel to another. Windows' internal file-system driver API is completely different from Linux'. Porting one file system not only requires a lot of knowledge about the different kernel APIs, but also about the file system itself, because most likely the file-system code is not cleanly separated from the kernel-specific code; you can't just sit down and write an adapter layer. (This is actually mostly speculation, but based on casual perusal of some existing driver code.)
There will be viable, open-source file systems on Windows the day somebody takes the time and effort do implement (and maintain) one. As for myself, I bought the book and started; I gave up not because it was technically challenging, but because it was no fun, and there were more interesting knowledge out there that I wanted to store in my brain.
Really, the issue is getting Windows to mount a drive which is not FAT/FAT32/ISO9660/NTFS. In order for an OS to mount a filesystem, there must be logic coded into the OS which will allow it to parse the file allocation tables and other information (journaling, etc.) and read and write files from/to the disk in that format. To the best of my knowledge, Microsoft has never supported any FS other than its own for HDD usage.
Fortunately for you, MS does have a filesystem-abstraction mechanism known as SMB, which several projects (most notably the SAMBA project) have implemented. These systems communicate with Windows via SMB, presenting information to the OS with parameters it understands. By proxy, then, the MS OS doesn't care a whit about what back end FS it's writing to - as far as it's concerned, it's just like any other MS OS via the network.
So probably the best solution is to have a network-mounted drive connected via a high-speed link (gigabit ethernet, etc.) on a linux box running SMB. If you do it right, you should hopefully have enough bandwidth to do your video and have it hosted wherever you like.
Good luck!
May work!!
/etc/nsswitch.conf
Its read-only, command-line access!
You type commands like this:
extdump \\.\PHYSICALDRIVE1 -o 68b3cb000
If you want to read a file.
Sam
blog.sam.liddicott.com
FAT32 is anything but slow. It's probably at or near the top of the list of fastest filesystems. It's so simple, how could it not be?
s/FAT32/bubble sort/
I'm afraid that I can't agree with you.
"Simplicity" doesn't mean much from a computer science standpoint (Does little code need to run? Few disk accesses required?)
One reason why FAT32 is slow is that its space allocation data structure looks something like a linked list, whereas traditional *IX filesystems look like a tree. To seek to a random point in a file on FAT32 requires O(n) time where n is the filesize. To do the same on *IX filesystems requires O(log(n)) time. A linked list is a poor data structure for position-based seeking because it doesn't take significant advantage of the fact that blocks can be pre-ordered by position.
May we never see th
- This was actually asked sometime ago, sort of - the answer is OpenAFS
It's not the answer. OpenAFS is not a local file system, which is what the original poster is asking about. OpenAFS is a distributed, networked file system implemented on top of an existing physical file system; it stores its files in whatever file system you're running, so on Windows it would be using NTFS or FAT.Couple of things to check.
First, it sounds like you have two different partitions on the same hard drive. That's a no-no for benchmarks. The first partition (the one at the outer edge of the disk) will always have much better performance than the second partition (the one closer to the middle). The disk spins at a constant RPM, but the outer cylinders have more tracks on them, so you get more data per revolution.
Second, the 1k default "segment" size for NTFS (cluster, methinks) only kicks in for fairly small disks. It is an explicit tradeoff between throughput and space efficiency. By using 1k clusters, you get a lower proportion of wasted space, but you have to spend more effort tracking down all of the additional clusters. With 16k clusters, you get a higher transfer rate at the cost of more space wasted per file. With a sufficiently larget disk, NTFS defaults to 4k clusters, which is a good default for most people. NTFS performance doesn't increase much after 4k for the average workload, and due to "resident" data streams, this doesn't waste much disk space either.
In any case, my experience has been that the performance difference between NTFS and FAT (which has never seemed to be very much) is way less significant than the reliability and extra features offered.
Time flies like an arrow. Fruit flies like a banana.
I do exactly the same thing, and eventually I decided the smartest way would be to use a networked filesystem. I have my DV box with mirrored (essential in my mind) 120GB drives running Debian and sharing via NFS over a 100Mb network. You could use any operating system on that box and it wouldn't matter.
I can rip DV footage to it with no lost frames and no problems. I also do a lot of audio recording, and can record at least 12 simultaneous tracks to it.
I can access it from any computer, it's never down, I don't have to restart to get into my files, everything just works!
You might have just hit it.
The issue with wanting everthing OSS on windows is that it makes migration easier. Almost every company has 1 or 2 apps that have to be on windows...so the key is replacing one-at-a-time...mozilla here, openoffice.org there... It's a page right out of the MS playbook...cooperate with everything and quietly switch user bases. But with OSS you won't ever be FORCED to switch and pay more money!!!
But write support is no longer marked experimental in the 2.6 kernel.
For good reason I'd say, I've been using NTFS write support for the past several revisions without a single hiccup.
First I was cautious and ginger in my handling of NTFS writes, and then more bold. Now I don't consider corruption anymore than I would with windows. I guess that comes from hundreds if not thousands of writes without a single issue *shrugs*.
In any case, if the kernel maintainers think it's safe to take off the experimental tag, and I've used it without any problems. Maybe it'll go well for you too.
NTFS write used to be horrid, and required external cleanup utils just to use. That's long long gone, if you've been afraid to touch it because of being burned in the past, seriously, it's time to try again.
How about installing a NFS client on your windows workstation and make yourself a NFS file server with a linux 2.6.x kernel?
Gigabit ethernet card are cheap these days and you can get yourself a nice SATA raid that will be able to handle your huge DV files.
Seb