From: Doug Freyburger on
Aragorn wrote:
>
> That said, reiserfs wasn't all that bad, but if it did ever go wrong,
> then it went wrong very badly, and it lacked a decent toolchain like
> ext2/3/4 or XFS

Lacking such tools puts ReiserFS out of the quesiton for me. EXT3 works
and it works fine for any of my production database boxes.

I will point out that a part of the core tool chain is a working dump
and restore for the filesystem format. That is something lacking across
Linux in general. I get that Linus doesn't like dump and prefers tar.
To me that is a significant feature missing and a point against using
Linux in production at all. But it's only one point in a long list.
Still, it is as ridiculous that those tools are missing as it is that I
am not on SourceForge contributing to them. Such is how Linux works
after all. If I think it's broken I can fix it myself.

> I have no real experience with JFS, but I presume it
> also has a similarly elaborate toolchain, since it is the default
> filesystem in AIX.

AIX JFS2 has a complete tool set. It works great. Extremely stable in
the face of basically everything. I've had disks fail to spin up after
a power cycle where I shook them, reinserted them, and started them up
again. A bunch of resync work later hello big Oracle database on them.

> Personally, I have however never heard of reiserfs
> making files disappear, but I did read somewhere that it's rather prone
> to damaging its own internal trees in the event of an unclean shutdown.

Regular UNIX filesystems have not been that bad since 1982. On a
VAX-11-750. That's a long time ago.
From: Aragorn on
On Friday 02 July 2010 21:54 in comp.os.linux.setup, somebody
identifying as Doug Freyburger wrote...

> Aragorn wrote:
>>
>> That said, reiserfs wasn't all that bad, but if it did ever go wrong,
>> then it went wrong very badly, and it lacked a decent toolchain like
>> ext2/3/4 or XFS
>
> Lacking such tools puts ReiserFS out of the quesiton for me. EXT3
> works and it works fine for any of my production database boxes.

Except that ext3 is rather slow "out of the box" because it has the
B-tree indexing disabled by default.

> I will point out that a part of the core tool chain is a working dump
> and restore for the filesystem format. That is something lacking
> across Linux in general.

Such utilities do exist for the ext? family of filesystems, and if a
distribution does not provide for them, then I imagine one could still
download and install them.

The "xfsprogs" package however contains the XFS equivalent of these
tools.

> I get that Linus doesn't like dump and prefers tar.

That is correct, yes.

> To me that is a significant feature missing and a point against using
> Linux in production at all.

Well, like I said, if you have an ext? filesystem and you need those
tools, then I'm sure they can still be found. Linus may not
like "dump" and "restore", but "/etc/fstab" still has the required
field for it. And XFS has those tools "out of the box".

That said, I personally also believe that there are far better tools for
making backups than "dump" and "restore".

>> Personally, I have however never heard of reiserfs making files
>> disappear, but I did read somewhere that it's rather prone to
>> damaging its own internal trees in the event of an unclean
>> shutdown.
>
> Regular UNIX filesystems have not been that bad since 1982. On a
> VAX-11-750. That's a long time ago.

Well, I never said reiserfs was the best filesystem. In fact, my
personal preference goes out to XFS, which is mature, fast, highly
advanced - albeit that the Linux port does not have all the features of
the IRIX version - it and comes with a complete toolchain.

--
*Aragorn*
(registered GNU/Linux user #223157)
From: Chris Cox on
Vitus Jensen wrote:
> Hej!
>
> As I have to open my server to windows users anyway I would like switch
> linux clients to cifs from nfs, too. Problem is that on each linux
> client there are several users who create files on the server and I need
> the owner of the file kept together with the file. With nfs it's
> "simple" by keeping uids insync between server and all clients. With
> cifs the file always gets the login name of client as owner :-(

I have worked with NFS and Samba for many, many years.

The closest thing that will work is:

1. Use NFS
2. Use Samba on the NFS Server
3. Join that server to the Windows domain
4. Allow Unix/Linux client hosts access via NFS
5. Windows clients will use normal Windows SMB/CIFS to reach the share

There is NO direct POSIX or POSIX with draft ACLs mapping to
Windows NTFS style permissions. However, some things DO work ok, others will
not. So, if any of this is interesting, you will need a filesystem with draft
POSIX ACLs enabled under Linux (which nowadays is pretty much all of the major
filesystem).

What will NOT work well:
Mounting Windows shares to a Linux/Unix box.

So... architecturally, I've learned the following for a mixed environment:

1. Linux should own DHCP and DNS for a Windows domain
2. Linux should own all file shares that are need across Unix/Linux + Windows
3. Linux file shares that are needed by Windows should be joined to the Windows
AD domain.

If you do these things, you'll be the closest you can get to a livable problem
free environment.

What does Windows get to own?
Active Directory

What does Windows NOT get to own:
1. DHCP
2. DNS
3. Windows file shares where Unix/Linux NFS + SMB/CIFS is desired.

Why?

Windows DHCP ONLY works well for Windows clients. And with that said, ditto for
dynamic DNS registrations as a part of that. The good news is that ISC BIND and
DHCP easily replace those Windows elements and it can be made to work with AD.

NFS works well across Unix/Linux clients (NFS4 less so just because it is newer
and not supported across all *ix variants well). NFS + Samba where the file
server is a AD Domain Member Server (i.e. joined to the domain) allows for NFS
and Samba to work in concert with regards to locking (read up on this as there
are variables to consider... and realize that commercial solutions usually end
up disabling locking). By using Samba on a Linux host, you also get to smash
the usernames with their AD names either by name or using a Samba smbusers file
to map them together. Alternatively, you can use winbind to dynamically create
the Linux accounts. Samba has the hooks to allow you to plug your own routine
in for local account creation as well if you do not want automatic winbind
account creation.

What dosen't work well with Linux owned Samba + NFS?

Areas where full NTFS permissions HAVE to be used. Again, there just isn't a
direct mapping... so NOT everything works. Thus, if a Windows share HAS to have
full NTFS permissions, IMHO, that share CANNOT be heterogeneous and needs to be
Windows ONLY. But for all other shares, use the Linux NFS + Samba technique.
You'll at least get a level of user and group level permissions that do work.

What REALLY REALLY does NOT work?

Letting Windows own heterogeneous shares. This tends to be what everyone WANTS
to do (as if Windows somehow cares about other OS's using their shares). It's a
BIG mistake and will only cause you massive frustration in the end. You'll get
next to NO permission mappings, you'll probably end up with a plethora of locked
out accounts over time, etc. AVOID.

Likewise with letting Windows own DHCP and DNS. It's just NOT compatible. In
truth, Windows really can't manage DHCP + DNS integration for its own dynamic
clients. It REALLY can't do it for non-Windows clients.

A well designed network CAN have both Windows AD and Unix/Linux clients all
working seamlessly together.. but you have to be willing to architect things
properly.

What also doesn't work well?

Windows NON domain based networking. Again, people seemed to be most interested
in a simple "home" style of network.... but even so, it's bad. Microsoft will
tell you that. So all the prior advice above assumes a Windows AD network. If
you're talking about a "home" (throwaway, don't care) network... then IMHO, all
bets are off anyhow. Whatever you create there will be a hodge podge mess anyhow.
From: The Natural Philosopher on
Chris Cox wrote:
> Vitus Jensen wrote:
>> Hej!
>>
>> As I have to open my server to windows users anyway I would like switch
>> linux clients to cifs from nfs, too. Problem is that on each linux
>> client there are several users who create files on the server and I need
>> the owner of the file kept together with the file. With nfs it's
>> "simple" by keeping uids insync between server and all clients. With
>> cifs the file always gets the login name of client as owner :-(
>
> I have worked with NFS and Samba for many, many years.
>
> The closest thing that will work is:
>
> 1. Use NFS
> 2. Use Samba on the NFS Server
> 3. Join that server to the Windows domain
> 4. Allow Unix/Linux client hosts access via NFS
> 5. Windows clients will use normal Windows SMB/CIFS to reach the share
>
> There is NO direct POSIX or POSIX with draft ACLs mapping to
> Windows NTFS style permissions. However, some things DO work ok, others will
> not. So, if any of this is interesting, you will need a filesystem with draft
> POSIX ACLs enabled under Linux (which nowadays is pretty much all of the major
> filesystem).
>
> What will NOT work well:
> Mounting Windows shares to a Linux/Unix box.
>
> So... architecturally, I've learned the following for a mixed environment:
>
> 1. Linux should own DHCP and DNS for a Windows domain
> 2. Linux should own all file shares that are need across Unix/Linux + Windows
> 3. Linux file shares that are needed by Windows should be joined to the Windows
> AD domain.
>
> If you do these things, you'll be the closest you can get to a livable problem
> free environment.
>
> What does Windows get to own?
> Active Directory
>
> What does Windows NOT get to own:
> 1. DHCP
> 2. DNS
> 3. Windows file shares where Unix/Linux NFS + SMB/CIFS is desired.
>
> Why?
>
> Windows DHCP ONLY works well for Windows clients. And with that said, ditto for
> dynamic DNS registrations as a part of that. The good news is that ISC BIND and
> DHCP easily replace those Windows elements and it can be made to work with AD.
>
> NFS works well across Unix/Linux clients (NFS4 less so just because it is newer
> and not supported across all *ix variants well). NFS + Samba where the file
> server is a AD Domain Member Server (i.e. joined to the domain) allows for NFS
> and Samba to work in concert with regards to locking (read up on this as there
> are variables to consider... and realize that commercial solutions usually end
> up disabling locking). By using Samba on a Linux host, you also get to smash
> the usernames with their AD names either by name or using a Samba smbusers file
> to map them together. Alternatively, you can use winbind to dynamically create
> the Linux accounts. Samba has the hooks to allow you to plug your own routine
> in for local account creation as well if you do not want automatic winbind
> account creation.
>
> What dosen't work well with Linux owned Samba + NFS?
>
> Areas where full NTFS permissions HAVE to be used. Again, there just isn't a
> direct mapping... so NOT everything works. Thus, if a Windows share HAS to have
> full NTFS permissions, IMHO, that share CANNOT be heterogeneous and needs to be
> Windows ONLY. But for all other shares, use the Linux NFS + Samba technique.
> You'll at least get a level of user and group level permissions that do work.
>
> What REALLY REALLY does NOT work?
>
> Letting Windows own heterogeneous shares. This tends to be what everyone WANTS
> to do (as if Windows somehow cares about other OS's using their shares). It's a
> BIG mistake and will only cause you massive frustration in the end. You'll get
> next to NO permission mappings, you'll probably end up with a plethora of locked
> out accounts over time, etc. AVOID.
>
> Likewise with letting Windows own DHCP and DNS. It's just NOT compatible. In
> truth, Windows really can't manage DHCP + DNS integration for its own dynamic
> clients. It REALLY can't do it for non-Windows clients.
>
> A well designed network CAN have both Windows AD and Unix/Linux clients all
> working seamlessly together.. but you have to be willing to architect things
> properly.
>
> What also doesn't work well?
>
> Windows NON domain based networking. Again, people seemed to be most interested
> in a simple "home" style of network.... but even so, it's bad. Microsoft will
> tell you that. So all the prior advice above assumes a Windows AD network. If
> you're talking about a "home" (throwaway, don't care) network... then IMHO, all
> bets are off anyhow. Whatever you create there will be a hodge podge mess anyhow.

Id agree with all of that except I dont use a windows domain and it
works fine.

But my requirements are not for shared data between many users on a
seamless prioritised and locked basis: the server merely acts as a
central repository for user data, that gets backed up..


From: phazr beam on
On Wed, 30 Jun 2010 07:34:00 +0200, Vitus Jensen came out of hiding to
write:

> Hej!
>
> As I have to open my server to windows users anyway I would like switch
> linux clients to cifs from nfs, too. Problem is that on each linux
> client there are several users who create files on the server and I need
> the owner of the file kept together with the file. With nfs it's
> "simple" by keeping uids insync between server and all clients. With
> cifs the file always gets the login name of client as owner :-(
>
> vitus(a)client$ touch as-vitus
> oe(a)client$ touch as-oe
> nobody(a)client$ touch as-nobody
> root(a)client# touch as-root
>
> ls -l
> -rw-r--r-- 1 vitus users 0 30. Jun 07:20 as-root
>
> Client: linux 2.6.27, mount.cifs 1.10 Server: reiserfs user_xattr, smbd
> Version 3.2.8
>
> Is this possible at all? Which part is responsible? xattr, acls? On
> client mounts or should the server filesystem support something special?
> acl is currently not enabled on reiserfs mounts.
>
> Vitus

Nope, leave your Linux NFS clients alone. NFS works much better than
CIFs clients, You can always mount a CIFS folder to a Linux client if
you think its necessary which I don't if it there as a NFS folder. The
only time you need to mount CIFs folders is when Windows is the server,
ie, MS SQL Server 2008, ???

Most of us want to get rid of the CIFs clients for NFS clients. IIRC,
Samba CIFs clogs the network with its broadcast packages.





--
phazr(a)beam.eternalseptember.net