headers
Alfred Perlstein | 4 Nov 2002 05:29

how does one know if you're using ufs2?

How do you know if you're using ufs1 or ufs2 disks?

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Permalink | Reply | 3 comments |
headers
Alfred Perlstein | 4 Nov 2002 09:34

snapshots+dump/restore

I'm cc'ing the those most involved with the current code.

When taking a dump(8) on a ufs filesystem with a snapshot node the
dump grabs the snapshot file and trys to dump it, shouldn't some
flag or something be set on the file that tells dump(8) to skip
over it?  If the semantics can be agreed on I can take a shot at
implementing a fix/workaround/whatever.  I particularly think
that dump should _never_ try to grab a .fsck_snapshot file.

Comments/suggestions?

--

-- 
-Alfred Perlstein [alfred <at> freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Permalink | Reply | 1 comment |
headers
Alfred Perlstein | 4 Nov 2002 09:45

statfs and how do show the users that they are using ufs2 vs ufs1?

I recently had the (mis)fortune of having to redo my filesystems
and I noticed that there doesn't seem to be an indicator of the
filesystem I've created/mounted being either ufs1 or ufs2.

As I started to drill down in the code I noticed some reentrancy
problems with the way that statfs(2) is done.  The kernel API
allows/encourages one to pass the cached statfs structure hung
off of the mount structure into the VFS_STATFS call.  This can/will
cause races in the code once Giant is pushed down into VFS.

So I'm wondering:
.) Do we really need the cached statfs structure? (I think leaving it
   is probably ok and will require less code changes)

.) Shouldn't we have a generic routine to copy in the constant values
   from the struct mount->statfs that the filesystem specific STATFS
   routine can call? (although we could add the call automagically to
   the VFS_STATFS macro.)

.) Shouldn't we stop passing in the 'cached' structure into the
   STATFS routine? (i think we should stop, it causes reentrancy issues)

.) Any problems with me taking a shot at making the statfs structure
   for ufs2 mounts have the string "ufs2" instead of "ufs"?
   (Any gotchas I should be aware of for this?)

Suggestions and comments appreciated.

thanks,
--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
FreeBSD bugmaster | 4 Nov 2002 20:00
Picon
Favicon

Current problem reports assigned to you

Current FreeBSD problem reports
Critical problems
Serious problems
Non-critical problems

S  Submitted   Tracker     Resp.    Description
-------------------------------------------------------------------------------
a [2000/10/06] kern/21807  fs       [patches] Make System attribute correspon

1 problem total.

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Permalink | Reply | 0 comments |
headers
Rashim Gupta | 6 Nov 2002 02:32
Picon
Favicon

Block alloc question


Hi,

   I have a question about the Block Alloc operation. When I have to log
a block alloc  operation, I think I need to log the Inode number of the
file, the  corresponding block and the position in the file where the
block is added. My question is how can I know at what position in the
file is the block added? What function/structure handles this operation?

--
Thanks
Rashim

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Permalink | Reply | 1 comment |
headers
Alfred Perlstein | 6 Nov 2002 03:39

Re: Block alloc question

* Rashim Gupta <guptar <at> cs.rpi.edu> [021105 17:33] wrote:
> 
> Hi,
> 
>    I have a question about the Block Alloc operation. When I have to log
> a block alloc  operation, I think I need to log the Inode number of the
> file, the  corresponding block and the position in the file where the
> block is added. My question is how can I know at what position in the
> file is the block added? What function/structure handles this operation?

see src/sys/ufs/ffs/ffs_alloc.c:ffs_alloc(ip, lbn, bpref, size, cred, bnp)

ip is the inode, and lbn seems to he the logical block offset into
the file, i'm not sure offhand what scaling needs to be applied
to 'lbn' to get the byte offset.

--

-- 
-Alfred Perlstein [alfred <at> freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Permalink | Reply | 0 comments |
headers
Robert Watson | 6 Nov 2002 17:21
Picon
Favicon

Re: how does one know if you're using ufs2?

It might be worth exporting this information via nmount using a 'version'
field, which would be set to a value of '1' if ufs1, and '2' if ufs2.
Since the file name string is tied up with things like module support, we
probably want to avoid tweaking that.

BTW, from a practical perspective, you can probe for UFS1 vs. UFS2 by
checking for extended attribute support using

error = extattr_get_file("/file/system/root", "", "", 0);

or something to that extent: UFS1, even with EA support, doesn't currently
support listing available EAs, whereas UFS2 does.  Exporting a version
string would be preferred.  mux <at>  CC'd because he's Mr Nmount.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert <at> fledge.watson.org      Network Associates Laboratories

On Sun, 3 Nov 2002, Alfred Perlstein wrote:

> How do you know if you're using ufs1 or ufs2 disks?
> 
> To Unsubscribe: send mail to majordomo <at> FreeBSD.org
> with "unsubscribe freebsd-fs" in the body of the message
> 

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Permalink | Reply | 2 comments |
headers
Alfred Perlstein | 6 Nov 2002 18:46

Re: how does one know if you're using ufs2?

* Robert Watson <rwatson <at> freebsd.org> [021106 08:21] wrote:
> It might be worth exporting this information via nmount using a 'version'
> field, which would be set to a value of '1' if ufs1, and '2' if ufs2.
> Since the file name string is tied up with things like module support, we
> probably want to avoid tweaking that.

I think this sort of info should be returned via statfs(2).  Some things
have picked up here but I'll be having a shot at it soon.

-Alfred

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Permalink | Reply | 1 comment |
headers
Jake Burkholder | 6 Nov 2002 19:12
Picon

Re: how does one know if you're using ufs2?

Apparently, On Wed, Nov 06, 2002 at 09:46:58AM -0800,
	Alfred Perlstein said words to the effect of;

> * Robert Watson <rwatson <at> freebsd.org> [021106 08:21] wrote:
> > It might be worth exporting this information via nmount using a 'version'
> > field, which would be set to a value of '1' if ufs1, and '2' if ufs2.
> > Since the file name string is tied up with things like module support, we
> > probably want to avoid tweaking that.
> 
> I think this sort of info should be returned via statfs(2).  Some things
> have picked up here but I'll be having a shot at it soon.

You can find out with dumpfs.

Jake

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Permalink | Reply | 0 comments |
headers
BOUWSMA Beery | 7 Nov 2002 16:48
Picon

B0rken -current handling of UFS1 filesystems with 64k block size...

[IPv6-only address above; strip the obvious for IPv4-only mail]

Howdy y'all,

I'm trying to track down why many parts of -current seem to have been
broken when handling filesystems I've been successfully using with
-stable (and with ancient -current), that I created with 64k block size.

It seems that dumpfs (in particular, since it's easiest to try) worked
fine as of 19.Jun (before the UFS2 commit) based on a binary found on
current.freeebsd.org, while 07.Jul binary (one of only a few available
before the libufs commit) fails just as a binary from today.

It appears that that since 21.Jun (the UFS2 commit), the search for a
superblock happens first at a location 64k into the disk (default UFS2
location), then at 8k (original UFS1 location), then at the beginning
(floppies), then at 256k (piggy location)?  That's what ufs/ffs/fs.h
implies to me.

If I have a UFS1 filesystem that I created with 64k block size, is it
possible that in addition to the real superblock at 8k, there is an
alternate superblock, or something similar, at 64k, which is found,
but which does not have the up-to-date data, which confuses dumpfs,
fsck, df, and who knows what all, under -current?

In fact, adding debugging to libufs/sblock.c indicates that the bogus
superblock info I see is found by the search at a 64k offset, and that
by ignoring this data, I get the proper data when the search continues
at the 8k offset.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane