zfs discuss - Jan 2007 - Differences between ZFS and UFS.

Skipped content of type multipart/signed-------------- next part --------------
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

>Bascially ZFS pass all my tests (about 3000). I see one problem with UFS
>and two differences:
That''s good; do you have those tests published anywhere.
>1. link(2) manual page states that privileged processes can make
>   multiple links to a directory. This looks like a general comment, but
>   it''s only true for UFS.
Solaris UFS doesn''t deal gracefully with that.  (Fsck will complain and
fix the fs and two fsck passes are generally needed.)

An argument can be made to ban this for UFS too.

(Some of the other fses do support this, like tmpfs)
>2. link(2) in UFS allows to remove directories, but doesn''t allow
this
>   in ZFS.
Link with the target being a directory and the source a any file or
only directories?  And only as superuer?
>3. Unsuccessful link(2) can update file''s ctime:
>
>	# fstest mkdir foo 0755
>	# fstest create foo/bar 0644
>	# fstest chown foo/bar 65534 -1
>	# ctime1=`fstest stat foo/bar ctime`
>	# sleep 1
>	# fstest -u 65534 link foo/bar foo/baz   <--- this unsuccessful
operation >updates ctime
>	EACCES
>	# ctime2=`fstest stat ${n0} ctime`
>	# echo $ctime1 $ctime2
>	1167440797 1167440798
Bug, I''d say.

Casper
_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org

>However, it gets interesting when SVID3 comes into play:
>
><snip>
>   The link(BA_OS) and unlink(BA_OS) descriptions in SVID3 both specify that
>   a process with appropriate privileges is allowed to operate on a
>directory.
>   We have claimed to conform to SVID3 since Solaris 2.0 and have not
>announced
>   that we ever plan to EOL SVID3 conformance.
><snip end>
This seems to allow an escape route; we can declare that no process
has sufficient privileges to link()/unlink() directories :-)

Casper
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Skipped content of type multipart/signed-------------- next part --------------
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

>> Link with the target being a directory and the source a any file or
>> only directories?  And only as superuer?
>
>I''m sorry, I ment unlink(2) here.
Ah, so symmetrical with link(2) to directories.

unlink(2) doesn''t always work and rmdir(2) will not remove empty
directories
with a link count other than 2 (for "." and "..")

You can''t unlink "." or ".."; though in early days
it was what was used
to create directories.  (mknod dir , link(dir, dir/.) , link(., dir/..))

I think removing the ability to use link(2) or unlink(2) on directories
would hurt no-one and would make a few things easier.

Casper
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Sat, 30 Dec 2006 15:50:53 +0100, <Casper.Dik@Sun.COM> wrote:
>
>>> Link with the target being a directory and the source a any file or
>>> only directories?  And only as superuer?
>>
>> I''m sorry, I ment unlink(2) here.
>
> Ah, so symmetrical with link(2) to directories.
>
> unlink(2) doesn''t always work and rmdir(2) will not remove empty
> directories
> with a link count other than 2 (for "." and "..")
>
> You can''t unlink "." or ".."; though in early
days it was what was used
> to create directories.  (mknod dir , link(dir, dir/.) , link(., dir/..))
>
> I think removing the ability to use link(2) or unlink(2) on directories
> would hurt no-one and would make a few things easier.
I''d be rather carful here, see the standards implications drafted in
4917742.

---
frankB
_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org

On Sat, 30 Dec 2006 02:28:49 +0100, Pawel Jakub Dawidek <pjd@FreeBSD.org>
wrote:
> Hi.
>
> Here are some things my file system test suite discovered on Solaris ZFS
> and UFS.
>
> Bascially ZFS pass all my tests (about 3000). I see one problem with UFS
> and two differences:
>
> 1. link(2) manual page states that privileged processes can make
>    multiple links to a directory. This looks like a general comment, but
>    it''s only true for UFS.
>
> 2. link(2) in UFS allows to remove directories, but doesn''t allow
this
>    in ZFS.
both are actually correct, the standards wording permits either way:

<snip link(2)/unlink(2) POSIX IEEE Std 1003.1, 2004 Edition>
If path1 names a directory, link() shall fail unless the process has
appropriate
privileges and the implementation supports using link() on directories.

The path argument shall not name a directory unless the process has
appropriate
privileges and the implementation supports using unlink() on directories.
<snip end>

UFS does support link(2)/unlink(2) with appropriate privilidges of
directories
while ZFS does not.

However, it gets interesting when SVID3 comes into play:

<snip>
   The link(BA_OS) and unlink(BA_OS) descriptions in SVID3 both specify that
   a process with appropriate privileges is allowed to operate on a
directory.
   We have claimed to conform to SVID3 since Solaris 2.0 and have not
announced
   that we ever plan to EOL SVID3 conformance.
<snip end>
> 3. Unsuccessful link(2) can update file''s ctime:
>
> 	# fstest mkdir foo 0755
> 	# fstest create foo/bar 0644
> 	# fstest chown foo/bar 65534 -1
> 	# ctime1=`fstest stat foo/bar ctime`
> 	# sleep 1
> 	# fstest -u 65534 link foo/bar foo/baz   <--- this unsuccessful
> operation updates ctime
> 	EACCES
> 	# ctime2=`fstest stat ${n0} ctime`
> 	# echo $ctime1 $ctime2
> 	1167440797 1167440798
>
I''d call this a bug, although the standard does not presicely mentions
this,
but at least it sais:

<snip link(2) POSIX IEEE Std 1003.1, 2004 Edition>
Upon successful completion, link() shall mark for update the st_ctime
field of the file.
Also, the st_ctime and st_mtime fields of the directory that contains the
new entry shall be marked for update.

If link() fails, no link shall be created and the link count of the file
shall remain unchanged.
<snip end>

Since we fail the successfull completion part and we should stay away from
modifying
the link count in that case I think it makes a good argument to also
require us to
stay away from updating the ctime as well.

--
frankB

(I''d rather be a forest than a street....)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

>> I think removing the ability to use link(2) or unlink(2) on directories
>> would hurt no-one and would make a few things easier.
>
>I''d be rather carful here, see the standards implications drafted
in
>4917742.
The standard gives permission to disallow unlink() on directories:

    "The path argument shall not name a directory unless the process has
    appropriate privileges and the implementation supports using unlink()
    on directories."

The ZFS implementation disallows it.

Casper
_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org

On 12/30/06, Casper.Dik@sun.com <Casper.Dik@sun.com>
wrote:
>
> >However, it gets interesting when SVID3 comes into play:
> >
> ><snip>
> >   The link(BA_OS) and unlink(BA_OS) descriptions in SVID3 both specify
that
> >   a process with appropriate privileges is allowed to operate on a
> >directory.
> >   We have claimed to conform to SVID3 since Solaris 2.0 and have not
> >announced
> >   that we ever plan to EOL SVID3 conformance.
> ><snip end>
>
> This seems to allow an escape route; we can declare that no process
> has sufficient privileges to link()/unlink() directories :-)
Ahhh... the good old standard excuse of Sun Microsystems to do nothing :) :) :)

Holger
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Sat, 30 Dec 2006 18:13:04 +0100, <Casper.Dik@Sun.COM> wrote:
>
>>> I think removing the ability to use link(2) or unlink(2) on
directories
>>> would hurt no-one and would make a few things easier.
>>
>> I''d be rather carful here, see the standards implications
drafted in
>> 4917742.
>
> The standard gives permission to disallow unlink() on directories:
>
>     "The path argument shall not name a directory unless the process
has
>     appropriate privileges and the implementation supports using unlink()
>     on directories."
>
> The ZFS implementation disallows it.
I''d be more then happy to see this feature disappearing from UFS as
well.

---
frankB
_______________________________________________
ufs-discuss mailing list
ufs-discuss@opensolaris.org