headers
George Morgan | 1 Nov 2004 14:51
Favicon

Re: msdosfs on D70

Are you trying to mount the filesystem through the camera or using a card
reader?

(BTW, I have a D70 also, but am not using a microdrive with it.  Microdrives are
big, but they are also slow.)

George Morgan

Quoting Gary Corcoran <garycor <at> comcast.net>:

> Wesley Morgan wrote:
>
> > On Sat, 30 Oct 2004, Gary Corcoran wrote:
> >
> >> Wesley Morgan wrote:
> >>
> >>> I can't seem to mount the FAT32 fs created by my D70. Windows and
> >>> mtools both are able to read it just fine. Has anyone encountered
> >>> this problem?
> >>> The output from fdisk and "minfo" are below. Perhaps someone can get
> >>> this working properly! :)
> >>
> >>
> >> Somebody might be able to help you if you explained
> >> what a "D70" is...
> >
> >
> > Sorry, slipped my mind. It's a digital camera, a "Nikon D70" as
> > indicated in the disk label.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wesley Morgan | 1 Nov 2004 18:01

Re: msdosfs on D70

On Mon, 1 Nov 2004, George Morgan wrote:

> Are you trying to mount the filesystem through the camera or using a card
> reader?
>
> (BTW, I have a D70 also, but am not using a microdrive with it.  Microdrives are
> big, but they are also slow.)

I've tried it from the camera, a usb card reader, and a pccard adapter - 
all with the same result. It's probably has something to do with fat32.

> Quoting Gary Corcoran <garycor <at> comcast.net>:
>
>> Wesley Morgan wrote:
>>
>>> On Sat, 30 Oct 2004, Gary Corcoran wrote:
>>>
>>>> Wesley Morgan wrote:
>>>>
>>>>> I can't seem to mount the FAT32 fs created by my D70. Windows and
>>>>> mtools both are able to read it just fine. Has anyone encountered
>>>>> this problem?
>>>>> The output from fdisk and "minfo" are below. Perhaps someone can get
>>>>> this working properly! :)
>>>>
>>>>
>>>> Somebody might be able to help you if you explained
>>>> what a "D70" is...
>>>
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nehal | 6 Nov 2004 00:17
Picon

ufs2 access from windows

i have just released ufs2tools-0.4 , this contains a command line
utility for reading ufs2 filesystems from windows 2000/XP (as
opposed to http://ffs.szm.sk/en/ which is a filesystem driver).

url: http://ufs2tools.sourceforge.net/

although the code is, afaik, clean and bug-free, the
implementation probably isn't the best. i've implemented it most
from scratch except for using the following files from
freebsd src: ffs/fs.h, ufs/dinode.h, ufs/dir.h

i would appreciate it if someone could go over the code and give
me tips on how i could improve or optimize the code. i've noticed
that retrieving many small files can be slow, this is because it
has to lookup the directory name each time, i could probably add
some sort of hash/lookup table to speed it up. i'm not sure what
else could be done.

i have looked over the code in freebsd src, but it was quite
complex and i couldn't understand much of it.
-- Nehal
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Nate Collins | 17 Nov 2004 00:39

Cannot build hfs-freebsd-03p2 on 5.3

Experiencing compile problems with hfs-freebsd-03p2 on 5.3

Any suggestions appreciated

Yar you still out there?

Here's the output:

# cd /tmp
# tar xvfz hfs-freebsd-03p1.tar.gz
# cd hfs-freebsd-03p1
# make

Warning: Object directory not changed from original
/tmp/hfs-freebsd-03p2/freebsd/mount_hfs
cc -O -pipe  -I/usr/src/sbin/mount
-I/tmp/hfs-freebsd-03p2/freebsd/mount_hfs/../../darwin/xnu/bsd -g  -c
mount_hfs.c
mount_hfs.c:55:21: mntopts.h: No such file or directory
mount_hfs.c:57: error: elements of array `mopts' have incomplete type
mount_hfs.c:58: error: `MOPT_STDOPTS' undeclared here (not in a function)
mount_hfs.c:58: error: initializer element is not constant
mount_hfs.c:58: error: (near initialization for `mopts[0]')
mount_hfs.c:59: error: `MOPT_FORCE' undeclared here (not in a function)
mount_hfs.c:59: error: initializer element is not constant
mount_hfs.c:59: error: (near initialization for `mopts[1]')
mount_hfs.c:60: error: `MOPT_UPDATE' undeclared here (not in a function)
mount_hfs.c:60: error: initializer element is not constant
mount_hfs.c:60: error: (near initialization for `mopts[2]')
mount_hfs.c:61: warning: excess elements in struct initializer
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yar Tikhiy | 17 Nov 2004 22:08
Picon

Re: Cannot build hfs-freebsd-03p2 on 5.3

On Tue, Nov 16, 2004 at 06:39:40PM -0500, Nate Collins wrote:
> Experiencing compile problems with hfs-freebsd-03p2 on 5.3
> 
> Any suggestions appreciated
> 
> Yar you still out there?

At least, I'm doing my best to :-)
As for your case, I can't but quote the Prerequisites section of
my HFS page:

	The source code of mount(8) must be installed at
	/usr/src/sbin/mount.

You really need it to build mount_hfs.

> Here's the output:
> 
> # cd /tmp
> # tar xvfz hfs-freebsd-03p1.tar.gz
> # cd hfs-freebsd-03p1
> # make
> 
> Warning: Object directory not changed from original
> /tmp/hfs-freebsd-03p2/freebsd/mount_hfs
> cc -O -pipe  -I/usr/src/sbin/mount
> -I/tmp/hfs-freebsd-03p2/freebsd/mount_hfs/../../darwin/xnu/bsd -g  -c
> mount_hfs.c
> mount_hfs.c:55:21: mntopts.h: No such file or directory
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Roberson | 20 Nov 2004 06:24

Giantless VFS.

I have a patch that I would like people to test and review.  It's
available here:

http://www.chesapeake.net/~jroberson/smpffs.diff

The short description:
This patch removes Giant from the read(), write(), and fstat() syscalls,
as well as page faults, and bufdone (io interrupts) when using FFS.  It
adds a considerable amount of locking to FFS and softupdates.  You may
also use non ffs filesystems concurrently, but they will be protected by
Giant.  If you are using quotas you should not yet run this patch.  I have
done some buildworlds, but any heavy filesystem activity would be
appreciated.

Long description:
There is now a per mount-point mutex in struct ufsmount that covers ffs's
struct fs related allocation routines.  The rest of the filesystem was
already covered by the buffer locks on cgs, indirs, etc, as well as a few
mutexes that were already in place.  I made great attempts to minimize the
number of lock operations for the common cases which resulted in a couple
of functions which may be entered with the UFS lock held, but return
without it held.  Where this is not already done, it will be documented in
comments.

The softupdate lk lock has been turned into a mutex, and it now protects
all global worklists, inode and page dep hash buckets, etc.
interlocked_sleep() is gone now that BUF_LOCK() and msleep() take
interlock arguments.  getdirtybuf() has been slightly changed to solve
some sleep related races that I disucssed with Kirk.  For now there is a
single softupdates mutex, but eventually it will be made per-mountpoint
(Continue reading)

Permalink | Reply | 0 comments |
headers
daemon | 26 Nov 2004 07:17

Sprint.has.received.your.email[NOC]

THIS IS AN AUTO-ACKNOWLEDGEMENT - PLEASE DO NOT RESPOND TO THIS EMAIL.

Sprint has received your email to our IP Network Operations Center.  Our
goal is to respond to your request within 72 hours.

Thank you for contacting Sprint. 

For more information visit us on the web at www.sprint.net
<http://www.sprint.net>.
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
orville weyrich | 29 Nov 2004 07:58
Picon
Favicon

FDISK Woes

I did a stupid thing and zapped my system disk
(/dev/ad0) with FDISK and Label (in
/stand/sysinstall)instead of /dev/da0.  Needless to
say, my system is sick.

Is there a way to mount this zapped system disk into
another system and reconstruct the disk label?  (I
need to find the locations of the / (ad0s1a), /usr
(ad0s1f), and /var (ad0s1e), and then write a suitable
disk label without destroying the data on the disk.

I feel so dumb doing this, but it seems strange that 
would allow me to zap the label of a mounted disk.

Anyway, please help me save my system!

TIA

orvile.

		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henry Whincup | 29 Nov 2004 20:00
Picon

ffs_clusteralloc: allocated out of group on 5TB fs (5.3-Stable)

On a machine with a 5TB array I created a single partition via gpt and a 
filesystem using the defaults from newfs.

All seemed well until I tried to fill the partition with data.  With "only" 
870GB or so used utilities started reporting the disk as full. Shortly (a 
few hours) after the machine panic'd.

During this time I had been trying to copy file via nfs and rsync onto the 
array.  After several crashes I tried a simple "dd if=/dev/zero of=./file" 
and after writing ~33GB the machine rebooted (the panic details below are 
from this reboot)

Details follow:

# ls -l /fs/VLargeZeroFile
-rw-r--r--  1 root  wheel  35446063104 Nov 29 15:00 /fs/file
# gpt -r -v show /dev/da0
gpt show: /dev/da0: mediasize=5597405642752; sectorsize=512;
blocks=10932432896
        start         size  index  contents
            0            1         PMBR
            1            1         Pri GPT header
            2           32         Pri GPT table
           34  10932432829      1  GPT part - FreeBSD UFS/UFS2
  10932432863           32         Sec GPT table
  10932432895            1         Sec GPT header
# df -h /fs
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/da0p1    4.9T    897G    3.7T    19%    /fs
# df -ki /fs
(Continue reading)

Permalink | Reply | 0 comments |

Gmane