Revision tags: release/2.0 |
|
#
c3c6d51e |
| 27-Sep-1994 |
Poul-Henning Kamp <phk@FreeBSD.org> |
Added declarations, fixed bugs due to missing decls. At least one of them could panic a system. (I know, it paniced mine!).
|
#
27a0bc89 |
| 19-Sep-1994 |
Doug Rabson <dfr@FreeBSD.org> |
Added msdosfs.
Obtained from: NetBSD
|
#
23b6c230 |
| 28-Feb-2010 |
Konstantin Belousov <kib@FreeBSD.org> |
Add per-mountpoint lockmgr lock for msdosfs. It is intended to be used as fat bitmap lock and to replace global mutex protecting fileno rbtree.
Tested by: pho MFC after: 3 weeks
|
Revision tags: release/7.2.0_cvs, release/7.2.0 |
|
#
1829d5da |
| 12-Mar-2009 |
Warner Losh <imp@FreeBSD.org> |
Update the projects tree to a newer FreeBSD current.
|
#
c72ae142 |
| 27-Feb-2009 |
John Baldwin <jhb@FreeBSD.org> |
- Hold a reference on the cdev a filesystem is mounted from in the mount. - Remove the cdev pointers from the denode and instead use the mountpoint's reference to call dev2udev() in getattr().
Rev
- Hold a reference on the cdev a filesystem is mounted from in the mount. - Remove the cdev pointers from the denode and instead use the mountpoint's reference to call dev2udev() in getattr().
Reviewed by: kib, julian
show more ...
|
Revision tags: release/7.1.0_cvs, release/7.1.0, release/6.4.0_cvs, release/6.4.0, release/7.0.0_cvs, release/7.0.0, release/6.3.0_cvs, release/6.3.0 |
|
#
fd7c4230 |
| 12-Jul-2007 |
Bruce Evans <bde@FreeBSD.org> |
Fix some bugs involving the fsinfo block (many remain unfixed). This is part of fixing msdosfs for large sector sizes. One of the fixed bugs was fatal for large sector sizes.
1. The fsinfo block h
Fix some bugs involving the fsinfo block (many remain unfixed). This is part of fixing msdosfs for large sector sizes. One of the fixed bugs was fatal for large sector sizes.
1. The fsinfo block has size 512, but it was misunderstood and declared as having size 1024, with nothing in the second 512 bytes except a signature at the end. The second 512 bytes actually normally (if the file system was created by Windows) consist of a second boot sector which is normally (in WinXP) empty except for a signature -- the normal layout is one boot sector, one fsinfo sector, another boot sector, then these 3 sectors duplicated. However, other layouts are valid. newfs_msdos produces a valid layout with one boot sector, one fsinfo sector, then these 2 sectors duplicated. The signature check for the extra part of the fsinfo was thus normally checking the signature in either the second boot sector or the first boot sector in the copy, and thus accidentally succeeding. The extra signature check would just fail for weirder layouts with 512-byte sectors, and for normal layouts with any other sector size.
Remove the extra bytes and the extra signature check.
2. Old versions did i/o to the fsinfo block using size 1024, with the second half only used for the extra signature check on read. This was harmless for sector size 512, and worked accidentally for sector size 1024. The i/o just failed for larger sector sizes.
The version being fixed did i/o to the fsinfo block using size fsi_size(pmp) = (1024 << ((pmp)->pm_BlkPerSec >> 2)). This expression makes no sense. It happens to work for sector small sector sizes, but for sector size 32K it gives the preposterous value of 64M and thus causes panics. A sector size of 32768 is necessary for at least some DVD-RW's (where the minimum write size is 32768 although the minimum read size is 2048).
Now that the size of the fsinfo block is 512, it always fits in one sector so there is no need for a macro to express it. Just use the sector size where the old code uses 1024.
Approved by: re (kensmith) Approved by: nyan (several years ago for a different version of (2))
show more ...
|
#
8e55bfaf |
| 10-Jul-2007 |
Bruce Evans <bde@FreeBSD.org> |
Don't use almost perfectly pessimal cluster allocation. Allocation of the the first cluster in a file (and, if the allocation cannot be continued contiguously, for subsequent clusters in a file) was
Don't use almost perfectly pessimal cluster allocation. Allocation of the the first cluster in a file (and, if the allocation cannot be continued contiguously, for subsequent clusters in a file) was randomized in an attempt to leave space for contiguous allocation of subsequent clusters in each file when there are multiple writers. This reduced internal fragmentation by a few percent, but it increased external fragmentation by up to a few thousand percent.
Use simple sequential allocation instead. Actually maintain the fsinfo sequence index for this. The read and write of this index from/to disk still have many non-critical bugs, but we now write an index that has something to do with our allocations instead of being modified garbage. If there is no fsinfo on the disk, then we maintain the index internally and don't go near the bugs for writing it.
Allocating the first free cluster gives a layout that is almost as good (better in some cases), but takes too much CPU if the FAT is large and the first free cluster is not near the beginning.
The effect of this change for untar and tar of a slightly reduced copy of /usr/src on a new file system was:
Before (msdosfs 4K-clusters): untar: 459.57 real untar from cached file (actually a pipe) tar: 342.50 real tar from uncached tree to /dev/zero Before (ffs2 soft updates 4K-blocks 4K-frags) untar: 39.18 real tar: 29.94 real Before (ffs2 soft updates 16K-blocks 2K-frags) untar: 31.35 real tar: 18.30 real
After (msdosfs 4K-clusters): untar 54.83 real tar 16.18 real
All of these times can be improved further.
With multiple concurrent writers or readers (especially readers), the improvement is smaller, but I couldn't find any case where it is negative. 342 seconds for tarring up about 342 MB on a ~47MB/S partition is just hard to unimprove on. (This operation would take about 7.3 seconds with reasonably localized allocation and perfect read-ahead.) However, for active file systems, 342 seconds is closer to normal than the 16+ seconds above or the 11 seconds with other changes (best I've measured -- won easily by msdosfs!). E.g., my active /usr/src on ffs1 is quite old and fragmented, so reading to prepare for the above benchmark takes about 6 times longer than reading back the fresh copies of it.
Approved by: re (kensmith)
show more ...
|
Revision tags: release/6.2.0_cvs, release/6.2.0, release/5.5.0_cvs, release/5.5.0, release/6.1.0_cvs, release/6.1.0, release/6.0.0_cvs, release/6.0.0, release/5.4.0_cvs, release/5.4.0 |
|
#
3b97f388 |
| 15-Mar-2005 |
Poul-Henning Kamp <phk@FreeBSD.org> |
Eliminate cdev pointer in inodes, they're not used or needed.
The cdev could have been pulled out of the mountpoint cheaper back when it was used anyway.
|
#
a30fc63b |
| 14-Mar-2005 |
Poul-Henning Kamp <phk@FreeBSD.org> |
Use vfs_hash instead of home-rolling.
|
Revision tags: release/4.11.0_cvs, release/4.11.0 |
|
#
d167cf6f |
| 06-Jan-2005 |
Warner Losh <imp@FreeBSD.org> |
/* -> /*- for copyright notices, minor format tweaks as necessary
|
Revision tags: release/5.3.0_cvs, release/5.3.0 |
|
#
9a135592 |
| 29-Oct-2004 |
Poul-Henning Kamp <phk@FreeBSD.org> |
Move MSDOSFS to GEOM backing instead of DEVFS.
For details, please see src/sys/ufs/ffs/ffs_vfsops.c 1.250.
|
#
3bc482ec |
| 03-Jul-2004 |
Tim J. Robbins <tjr@FreeBSD.org> |
By popular request, add a workaround that allows large (>128GB or so) FAT32 filesystems to be mounted, subject to some fairly serious limitations.
This works by extending the internal pseudo-inode-n
By popular request, add a workaround that allows large (>128GB or so) FAT32 filesystems to be mounted, subject to some fairly serious limitations.
This works by extending the internal pseudo-inode-numbers generated from the file's starting cluster number to 64-bits, then creating a table mapping these into arbitrary 32-bit inode numbers, which can fit in struct dirent's d_fileno and struct vattr's va_fileid fields. The mappings do not persist across unmounts or reboots, so it's not possible to export these filesystems through NFS. The mapping table may grow to be rather large, and may grow large enough to exhaust kernel memory on filesystems with millions of files.
Don't enable this option unless you understand the consequences.
show more ...
|
#
89c9c53d |
| 16-Jun-2004 |
Poul-Henning Kamp <phk@FreeBSD.org> |
Do the dreaded s/dev_t/struct cdev */ Bump __FreeBSD_version accordingly.
|
Revision tags: release/4.10.0_cvs, release/4.10.0, release/5.2.1_cvs, release/5.2.1 |
|
#
01ba334c |
| 17-Feb-2004 |
Tom Rhodes <trhodes@FreeBSD.org> |
Do not place dirmask in unnamed padding. Move it to the bottom of this list where it should have been added originally.
Prodded by: bde
|
Revision tags: release/5.2.0_cvs, release/5.2.0, release/4.9.0_cvs, release/4.9.0 |
|
#
c4f02a89 |
| 26-Sep-2003 |
Max Khon <fjoe@FreeBSD.org> |
- Support for multibyte charsets in LIBICONV. - CD9660_ICONV, NTFS_ICONV and MSDOSFS_ICONV kernel options (with corresponding modules). - kiconv(3) for loadable charset conversion tables support.
Su
- Support for multibyte charsets in LIBICONV. - CD9660_ICONV, NTFS_ICONV and MSDOSFS_ICONV kernel options (with corresponding modules). - kiconv(3) for loadable charset conversion tables support.
Submitted by: Ryuichiro Imura <imura@ryu16.org>
show more ...
|
#
c98a31ca |
| 12-Aug-2003 |
Tom Rhodes <trhodes@FreeBSD.org> |
Add a '-M mask' option so that users can have different masks for files and directories. This should make some of the Midnight Commander users happy.
Remove an extra ')' in the manual page.
PR: 3
Add a '-M mask' option so that users can have different masks for files and directories. This should make some of the Midnight Commander users happy.
Remove an extra ')' in the manual page.
PR: 35699 Submitted by: Eugene Grosbein <eugen@grosbein.pp.ru> (original version) Tested by: simon
show more ...
|
Revision tags: release/5.1.0_cvs, release/5.1.0, release/4.8.0_cvs, release/4.8.0, release/5.0.0_cvs, release/5.0.0, release/4.7.0_cvs, release/4.6.2_cvs, release/4.6.2, release/4.6.1, release/4.6.0_cvs |
|
#
d394511d |
| 16-May-2002 |
Tom Rhodes <trhodes@FreeBSD.org> |
More s/file system/filesystem/g
|
#
11caded3 |
| 19-Mar-2002 |
Alfred Perlstein <alfred@FreeBSD.org> |
Remove __P.
|
Revision tags: release/4.5.0_cvs, release/4.4.0_cvs |
|
#
d3990d58 |
| 28-Nov-2001 |
John Baldwin <jhb@FreeBSD.org> |
Axe more unused GEMDOS code that was #ifdef atari.
PR: kern/21809 Submitted by: <mbendiks@eunet.no>
|
#
64bf8541 |
| 27-Nov-2001 |
John Baldwin <jhb@FreeBSD.org> |
Remove GEMDOS support from msdosfs. I don't think anyone is going to port FreeBSD to Atari machines any time soon.
|
#
a13234bb |
| 25-Apr-2001 |
Poul-Henning Kamp <phk@FreeBSD.org> |
Move the netexport structure from the fs-specific mountstructure to struct mount.
This makes the "struct netexport *" paramter to the vfs_export and vfs_checkexport interface unneeded.
Consequently
Move the netexport structure from the fs-specific mountstructure to struct mount.
This makes the "struct netexport *" paramter to the vfs_export and vfs_checkexport interface unneeded.
Consequently that all non-stacking filesystems can use vfs_stdcheckexp().
At the same time, make it a pointer to a struct netexport in struct mount, so that we can remove the bogus AF_MAX and #include <net/radix.h> from <sys/mount.h>
show more ...
|
Revision tags: release/4.3.0_cvs, release/4.3.0, release/4.2.0, release/4.1.1_cvs |
|
#
ff4ad0c4 |
| 25-Aug-2000 |
Bruce Evans <bde@FreeBSD.org> |
Quick fix for msdsofs_write() on alphas and other machines with either longs larger than 32 bits or strict alignment requirements.
pm_fatmask had type u_long, but it must have a type that has precis
Quick fix for msdsofs_write() on alphas and other machines with either longs larger than 32 bits or strict alignment requirements.
pm_fatmask had type u_long, but it must have a type that has precisely 32 bits and this type must be no smaller than int, so that ~pmp->pm_fatmask has no bits above the 31st set. Otherwise, comparisons between (cn | ~pmp->pm_fatmask) and magic 32-bit "cluster" numbers always fail. The correct fix is to use the C99 type uint_least32_t and mask with 0xffffffff. The quick fix is to use u_int32_t and assume that ints have
msdosfs metadata is riddled with unaligned fields, and on alphas, unaligned_fixup() apparently has problems fixing up the unaligned accesses caused by this. The quick fix is to not comment out the NetBSD code that sort of handles this, and define UNALIGNED_ACCESS on i386's so that the code doesn't change on i386's. The correct fix would define UNALIGNED_ACCESS in a central machine-dependent header and maybe add some extra cases to unaligned_fixup(). UNALIGNED_ACCESS is also tested in isofs.
Submitted by: parts by Mark Abene <phiber@radicalmedia.com> PR: 19086
show more ...
|
Revision tags: release/4.1.0 |
|
#
432a8400 |
| 29-Jun-2000 |
Boris Popov <bp@FreeBSD.org> |
Fix memory leakage on module unload.
Spotted by: fixed INVARIANTS code
|
Revision tags: release/3.5.0_cvs, release/4.0.0_cvs |
|
#
01f6cfba |
| 27-Jan-2000 |
Yoshihiro Takahashi <nyan@FreeBSD.org> |
Supported non-512 bytes/sector format.
PR: misc/12992 Submitted by: chi@bd.mbn.or.jp (Chiharu Shibata) and Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Reviewed by: Dmitrij Tejblum <tejblum@arc.hq.cti
Supported non-512 bytes/sector format.
PR: misc/12992 Submitted by: chi@bd.mbn.or.jp (Chiharu Shibata) and Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Reviewed by: Dmitrij Tejblum <tejblum@arc.hq.cti.ru>
show more ...
|
#
c4473420 |
| 29-Dec-1999 |
Peter Wemm <peter@FreeBSD.org> |
Change #ifdef KERNEL to #ifdef _KERNEL in the public headers. "KERNEL" is an application space macro and the applications are supposed to be free to use it as they please (but cannot). This is cons
Change #ifdef KERNEL to #ifdef _KERNEL in the public headers. "KERNEL" is an application space macro and the applications are supposed to be free to use it as they please (but cannot). This is consistant with the other BSD's who made this change quite some time ago. More commits to come.
show more ...
|