Find the answer to your Linux question:
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 30 of 35
It doesn't use chains as FAT32 does, but every file has an array of block pointers, so even though it doesn't have to traverse the entire chain every file seek ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #21
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578

    It doesn't use chains as FAT32 does, but every file has an array of block pointers, so even though it doesn't have to traverse the entire chain every file seek (that's why FAT drivers should cache the chain; I don't know whether they actually do), it nonetheless needs to cache the block pointers for fast access. Caching is not as vital as in FAT since the block chain description is more intelligently designed and requires less seeks for non-cached access of large files, but it still needs to be cached for fast access.
    Like I've said: it's not like the entire FAT needs to be cached, just the chains that are actually in use. So it's not that different.
    Blocks are basically the UNIX synonym of clusters, and ext{2,3} does use FATs, only that they aren't called FATs, are much better designed and that each file has its own, instead of one large, global one. The FAT32 FAT also doubles as the block allocation bitmap on ext{2,3}.
    In fact, the block structure on ext{2,3} uses even more space than FAT, only that it's used on-demand. If all disk space on an ext{2,3} filesystem is used, it has block arrays as large as the FAT on a FAT32 filesystem (even a little larger because of the indirect blocks), and on top of that it must have the block usage and bad blocks bitmaps. The bitmaps admittedly just take a sixteenth of the space that the block arrays take, but it's nonetheless more space than the FAT on a equally sized FAT32 filesystem. I don't know if modern FAT file systems still use backup FATs, though. In that case, they'd take more disk space, but the backups don't need to be cached, though, so the same basic algoriths still apply.
    I'm not sure that I understood the reason you mentioned that ext2 can have smaller clusters. While it is true that the block arrays only grow on demand, they still are there.
    Btw, the file type isn't stored in the directory, but in the target inode. I'm not sure if that might have been a typo from your part, I just thought that I might include it to be sure.
    What you're saying about directories on UNIX file systems basically apply to FAT32 as well, only that each directory entry doubles as the inode structure. That's why you can't (properly) hard link files in a FAT32 file system. A directory is still just a file, though, that has the "directory" attribute set in its parent directory.

  2. #22
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Quote Originally Posted by Dolda2000
    It doesn't use chains as FAT32 does, but every file has an array of block pointers, so even though it doesn't have to traverse the entire chain every file seek (that's why FAT drivers should cache the chain; I don't know whether they actually do), it nonetheless needs to cache the block pointers for fast access. Caching is not as vital as in FAT since the block chain description is more intelligently designed and requires less seeks for non-cached access of large files, but it still needs to be cached for fast access.
    Like I've said: it's not like the entire FAT needs to be cached, just the chains that are actually in use. So it's not that different.
    Blocks are basically the UNIX synonym of clusters, and ext{2,3} does use FATs, only that they aren't called FATs, are much better designed and that each file has its own, instead of one large, global one. The FAT32 FAT also doubles as the block bitmaps on ext{2,3}.
    In fact, the block structure on ext{2,3} uses even more space than FAT, only that it's used on-demand. If all disk space on an ext{2,3} filesystem is used, it has block arrays as large as the FAT on a FAT32 filesystem (even a little larger because of the indirect blocks), and on top of that it must have the block usage and bad blocks bitmaps. The bitmaps admittedly just take a sixteenth of the space that the block arrays take, but it's nonetheless more space than the FAT on a equally sized FAT32 filesystem. I don't know if modern FAT file systems still use backup FATs, though. In that case, they'd take more disk space, but the backups don't need to be cached, though, so the same basic algoriths still apply.
    I'm not sure that I understood the reason you mentioned that ext2 can have smaller clusters. While it is true that the block arrays only grow on demand, they still are there.
    Btw, the file type isn't stored in the directory, but in the target inode. I'm not sure if that might have been a typo from your part, I just thought that I might include it to be sure.
    What you're saying about directories on UNIX file systems basically apply to FAT32 as well, only that each directory entry doubles as the inode structure. That's why you can't (properly) hard link files in a FAT32 file system. A directory is still just a file, though, that has the "directory" attribute set in its parent directory.

  3. #23
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Oops... I pressed the quote button instead of edit without realizing it.

  4. $spacer_open
    $spacer_close
  5. #24
    Linux User
    Join Date
    Jul 2002
    Location
    Daytona Beach, FL
    Posts
    487
    (liar - you just like listening to yourself talk(type) )
    majorwoo

    Quiet brain, or I\'ll stab you with a Q-tip.

  6. #25
    Linux Engineer
    Join Date
    Jan 2003
    Location
    Lebanon, pa
    Posts
    994
    I just checked and directory file does contain type of object so it doesn't have to check the inode itself but the current version of glibc doesn't use this yet. I agree that there is some more overhead with ext2(superblock, block group descriptor after the superblock, block bitmap, inode bitmap, inode table, inode, i think i remembered every part) but on larger hd's it actually saves space. Compare an 80GB hd, where fat32 will use 32KB clusters compared to 1KB, 2KB, 4KB you can use with ext2. What I meant by ext2 allowing smaller blocks is that you could never use say 1KB clusters with fat32 because the size of the FAT will grow exponentially on larger disks.

  7. #26
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    But what I'm trying to say is that at least FAT32 shouldn't per specification have to have 32 KB clusters. It should, as well as ext{2,3} be able to use 1 KB clusters, since it does have that addressing capability.
    What I'm trying to find out is why it actually does. The only reason I can think of is that MS has used some stupid pre-determined tables that they thought looked good at the time being, for some very good MS-like reason.
    Of course, I'm not trying to pretend that FAT32 is a filesystem worth considering - since it isn't, unless you want access from both linux and windows. I'm just trying to figure out just why it doesn't use a cluster size of 1 KB or so. After all, it can do so.
    I assume you were kidding when you said that the FAT will grow exponentially with the partition size, since we both know that's not true.
    Oh, and btw., I checked out what you were saying about the file type in the dir entry, and it turned out to be true. Apparently, they have devised a second version of the dir entry structure. In the first version, the file name length specifier was 16 bits. In the second version, they have chopped the second byte and made it store the file type. I don't really understand why they have done that, though. The file type is still mainly stored in the inode (since one inode, after all, can only be one file type, no matter how many names it might have), so the copy in the dir entry must be for caching purposes. Since the kernel only needs to find out the file type when it opens a file, it has to look up the inode anyway, it must be for the sake of userspace applications. That seems futile, though, since there's no syscall to retrieve that info anyway. For reading from directories, at least I know of only readdir(2), and that doesn't return the file type. It would only work on ext{2,3} file systems anyway, so it's ultimately unportable whatever you do.

    And majorwoo... really, what're those mushrooms you've been smoking lately? =)

  8. #27
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    OK... there is actually an undocumented syscall, "readdir64", which returns the file type. Anyway, it's still unportable, so no library in its right mind would use it.

  9. #28
    Linux Engineer
    Join Date
    Jan 2003
    Location
    Lebanon, pa
    Posts
    994
    Ok, it won't grow exponentialy but it will be very big. Remeber it will write 4B of data to the FAT for each cluster. Now if you have an 80GB drive with 1KB clusters, thats will be a fairly large FAT. Now I don't know how that will compare with an ext2 system and I'm pretty lazy right now to try and find out.

  10. #29
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    It all depends on the file distribution, of course, but the more larger files on an ext file system and the larger its block arrays will get (because of the indirect blocks), but a general rule of thumb is that it will be at least 106,25% of the equivalent FAT32 system, not counting backup sb's, inode tables and other metadata. Then, on the other hand, FAT direntries are larger the ext's direntries, but FAT doesn't need inode tables, on the other hand. An ext partition of the same physical size as a FAT one will always fit less data. But on the other hand, it does have certain advantages, though.
    That's providing that FAT32 systems nowadays doesn't have backup FATs, of course. Like I mentioned, I don't know whether they do.
    Anyway, one FAT with 1 KB clusters on a 80 GB partition will take appr. 300 MB.
    An ext fs on an equally sized partition will take at least as much block addressing space, plus appr. 20 MB for the block bitmaps. Then I don't remember how many backup sb's it stores and I'm too lazy to find out how much the inode tables will take on a normally configured partition. If all files are maximum sized, each file will also take about 64 MB in indirect blocks, too. Indirect blocks allow for faster seeking, so they're basically better, of course, but they do take disk space nonetheless. If all files are 8KB or less each, all block addressing data will of course be stored in the inode itself on an ext system, but that takes place anyway. It allows for immediate seeking, on the other hand.

    But all of that's really unimportant, since what I wanted to find out is why FAT32 uses so large clusters. Do you have any ideas?

  11. #30
    Just Joined!
    Join Date
    Jan 2003
    Posts
    9

    STOP!

    Can u just stop arguing
    can i format say 5gb of my ntfs disk as Fat32?

Page 3 of 4 FirstFirst 1 2 3 4 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •