Please read How to securely hash passwords? - you should not roll your own. @ThomasPornin has a great answer to that question, and the section on Salt Generation includes (among a lot more good advice) the following wisdom:
The main and only point of the salt is to be as unique as possible. Whenever a salt value is reused anywhere, this has the potential to help the attacker.
For instance, if you use the user name as salt, then an attacker (or several colluding attackers) could find it worthwhile to build rainbow tables which attack the password hashing function when the salt is "admin" (or "root" or "joe") because there will be several, possibly many sites around the world which will have a user named "admin". Similarly, when a user changes his password, he usually keeps his name, leading to salt reuse. snip
The cheap way to obtain uniqueness is to use randomness. If you generate your salt as a sequence of random bytes from the cryptographically secure PRNG that your operating system offers (/dev/urandom, CryptGenRandom()...) then you will get salt values which will be "unique with a sufficiently high probability". 16 bytes are enough so that you will never see a salt collision in your life, which is overkill but simple enough. snip
Essentially, you cannot use the password to generate a salt for the password, since the ONLY input is the password!
- Thus, an attacker still need only put "123456" into their hash generator once, and then they'll find all the thousands of users who used that as their password. If you had random salts, they'd have to try thousands of times (once per salt + password combination) to get those thousands of weak passwords.
You should use a random number generator to generate unique, per-user salts (and store them in plaintext in the database, along with the password hash and number of iterations or work factor used [so you can easily increase it later]), and the general advice here is for roughly a 16 byte random salt. 8 bytes is probably a practical minimum for length of the salt.